Server Setup

The questions below are due on Monday February 12, 2024; 10:00:00 AM.
 
You are not logged in.

Please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.mit.edu) to authenticate, and then you will be redirected back to this page.

For each of you, we set a Raspberry Pi server up and running in a closet somewhere. In this exercise, you'll remotely connect into and set up Nginx in this server.

Setting Up Remote Connection to Server

Static IP

Right now your Raspberry Pi is connected to the greater world via the internet. When it joins it, it is assigned a series of temporary identifying numbers which serve as an internet address. With this address, other computers on the global network can target information at it. However since the address is temporary and subject to change, the Raspberry Pi must be the one to initiate contact/exchanges between it and other machines. As a result, the Raspberry Pi is client-only because of its dyamic IP address ("IP" = "Internet Protocol"). For example, the Pi might contact google.com to conduct a query. In the initial request, it also notifies Google of its current temporary address, so when Google responds, it knows where to direct its traffic.

What we would like is for our Raspberry Pi to be globally accessible to other devices always via a fixed location on the internet, and for this we need to give it a permanent address. The emotional and technical burden of "starting" the conversation, therefore doesn't have to be on the Raspberry Pi's side. Instead it can sit and listen and since its location is known to other devices they can send incoming traffic. This is easier said than done, since there are only so many permanent addresses that can be given out and they are largely tightly regulated. Through some weird historical glitches, MIT is in posession of several million addresses, however, and will gladly give us some for our class. Kinda cool and nice of them when you think about it.

We've gone ahead and claimed/requested two things for you:

  • A unique IPv4 static IP, which for you is: ERROR
  • A DNS name to associate with that IP address, which for you is ERROR

Wait, you might say. I'm just reading a generic pset. You say, this value is unique to me, but my friends are also reading this. Well that's true, but I'm using your MIT credentials to drop in the correct info above. So it looks nice. Trust me, the number above is yours.

The "real" address is the static IP above. This is really what will be used to identify your machine behind the scenes to all other network connected devices in the world. The DNS name, ERROR, is really only for human consumption/readability....a convenient alias, if you will. We have already asked MIT to associate that DNS name with that unique static IP and they then notified the whole world about that. So a computer in Europe can send messages to either ERROR or ERROR and both will get to the affiliated machine1

Note you can't just do this for any computer anywhere. MIT owns several million IPV4 static IP addresses. I requested them from class for us. The internal network infrastructure of MIT has been prepared ahead of time to know and expect that a device "looking like" your address will get projected to the outside world. Also note that the appropriate bits to expose this IP address to the outside world have been set to work only within the MIT EECS building of 38 and 34. You can't expect this to work in your dorm.

We have also gone ahead and attached your Raspberry Pi to this static IP. Let's put this to the test!

SSH-ing In (Part I)

But first things first, can you access the Pi remotely? On your Raspberry Pi, there is an admin user. This account is intended for the staff to use when we may need log in to your server to better help you out in future psets.

We will be testing our remote connection by first using this admin login. On your laptop, go to a terminal (or shell) and do:

ssh student@ERROR

It should prompt you for the admin password. Enter pisecret and then hit Enter. Assuming it goes through you should find yourself suddenly logged into the Raspberry Pi over the internet.

Very cool.

Now you can remotely access it over ssh! This means that you'll be able to work on your Raspberry Pi and future psets anywhere in the world (including your dorm room so you don't have to physically come to lab).

Very nice.

Adding Your Login

Now, time to add your OWN login to your Raspberry Pi server! After this exercise, you will use this new account you created for future SSH connections. Create a username and password. We would strongly recommend you use your MIT kerberos None. Password can be whatever you want, just don't forget it.

Run this command to add your user login to your machine. If it prompts you to enter user information, just hit Enter to leave them blank.

sudo adduser None

We will also give your account sudo priveleges on the machine, meaning you can do whatever you want with it. Embrace this power, but also be responsible with it. To do this, we'll add the None user to the sudo group with this command:

sudo usermod -aG sudo None

To verify that this was completed successfully, run this command and you should see your user in the list.

getent group sudo

SSH-ing In (Part II: Now With Your Login)

Since your account is created, let's test it out too!

To close our current SSH connection, simply enter exit into the terminal and then hit Enter. You should see the following messages, as a result.

logout
Connection to ERROR closed.

Now, for the real REAL test. Can you access the Pi remotely with your OWN login? Using the same ssh command as before, we will try to establish a SSH connection, but using your user login.

ssh None@ERROR
`None@ERROR` is of the form [username]@[address], so if you set up your Pi with a username other than your kerb, you should use that here.

It should prompt you for your password. The same one that you created for your user! Enter the password.

This should log you into the Rapsberry Pi!

Initial Server Setup

Now that we got that out of the way, the first thing to do is to update and upgrade all software on the computer (the starting distribution are usually stable snapshots that can be months old). To do these updates/upgrades, do:

sudo apt update

This shouldn't take too long. Then do:

sudo apt upgrade

This will likely take a bit longer and also prompt you with a Y/n, make sure to say Y (for "Yes").

Nano or Vim or Emacs?

Your server is "headless" meaning there's no GUI to interact with it. As a result, you'll need to install and work with a terminal-based text editor. There are three big choices. In order from easiest to hardest, I'd say the options are Nano, Emacs, and then Vim. The choice is yours, but I'd encourage you to go towards an easier editor. Quick startup-guides are found for each below.

In addition, you'll need to install one of these editors on the machine (nano is actually probably already there) by doing sudo apt install nano or sudo apt install emacs or sudo apt install vim depending on your choice. Also feel free to try all three of these and see what you like. They are all unnatural coming from a point-n-click existence, but once you're going they aren't too bad, though vim's modes can be unnatural which is why I suggested nano or emacs first.

Nginx and the start of Greater Things

The last thing we want to do on our Raspberry Pi now is to get Nginx going. Nginx is a reverse proxy service that will allow us to redirect various incoming/outgoing tasks to different processes on our computer. Eventually what we'll let Nginx do is link incoming requests to Python processes that we'll be running. For now, we'll just use it to serve some static web content.

First install nginx:

sudo apt install nginx

Then do:

sudo systemctl enable nginx

and then

sudo systemctl start nginx

Nginx should be running. If you go and view the file (by using emacs, for example) at /etc/nginx/sites-available/default this is the configuration file for Nginx. Right now all it is doing is "serving" static files located in a particular location (/var/www/html) when any web traffic comes looking on port 80 over HTTP. What this means is we should be able to simply jump in a browser and visit your server at http://ERROR. If you do that, however you'll see that nothing happens and/or your browser hangs.

Similarly, going back to the previous exercise with the ESP32-C3, it should be targeting this web endpoint over HTTP, and if you investigate it now, you should still see it puking out the following on loop:

connection failed :/
wait 0.5 sec...

What is going on? Well, we haven't allowed HTTP traffic through. In order to do that we have to put another hole in our firewall. Do this by running:

sudo ufw allow http

Now refresh and/or revisit in the browser at: http://ERROR Bada Bing, Bada Boom, you should see some welcome to Nginx stuff showing up. A working HTML web page served over HTTP!

Now go back to your (hopefully still running ESP32-C3). Check the serial monitor. You should now be seeing the html of the nginx default splash page! Noice.

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

-->

This is very good news. It means that you have all the basics of your system working.

As a final thing, let's change what your basic splash page says. (Don't worry we'll add and route in a lot more stuff in future weeks). But for now on your server cd to /var/www/html.

In that directory you'll see a file called: index.nginx-debian.html. Rename it to just index.html with:

sudo mv index.nginx-debian.html index.html

Then go in and edit the file so that the ONLY text is your kerberos, None. Save it and revisit it in the browser. You should see just "None" in regular unformatted serif font that browsers default to.

Also check your ESP32-C3. In its serial monitor it should just be printing your kerberos on repeat. Extremely cool.

Just to make sure you really have done this, run the checker below which will look at your server and make sure it gets back what we expect (specifically that you are just returning your kerberos). I don't care what you put in the box, but the question will fire a request to your server endpoint to make sure you did what you should.

If this is all working, you're good to go. You now have two computational devices that can talk to one another from anywhere in the world, provided they are connected to the internet. This is not hyperbole. You could go to Australia, and assuming you have good internet, you could totally talk to your Raspberry Pi up here at MIT. Your Pi is now a "server" aka the "cloud".


 
Footnotes

1It'll usually take a day or so for this relationship to propagate outwards across the world as various DNS talk to one another periodically and update their records. Almost immediately after setting this up within MIT's network, this name will work. On the other side of the world, however, it may not be known yet. These names were aquired a few weeks ago so they've had plenty of time to make it all the way to Antarctica. (click to return to text)