Let’s Go to My Housecreated: 2023.01.24. 16:03 · modified: 2023.01.30. 00:32 · license
I’m writing this to celebrate successfully connecting the gunh.ee server to Ethernet today.
Here’s a shocking fact about gunh.ee: the server hosting it is a Raspberry Pi behind the TV in my living room.
With so many hosting services available, why did I take the hard route and set up a server computer myself? Well...
Hosting services fall into two broad categories: shared hosting and VPS hosting. The former is the cheapest way to launch a website, and it’s what I used for my first site, which I launched in the fall of my freshman year of college. The trouble is that the low price comes with limited flexibility. It supported everything needed to run a basic website, but I couldn’t run anything else. Of course, I didn’t know much back then, so it was plenty useful to me. I had a great time experimenting with and learning from the tools it provided.
By the end of my senior year, I wanted to do much more with my new server. I wanted to write and run my own web server in node.js, create APIs, and use it for things beyond the web. For that, I needed VPS hosting. With a VPS, I wouldn’t have the physical machine, but I could install and use whatever software I wanted within the space allocated to me. The company I’d used as a freshman offered VPS hosting too, but this time I decided to try AWS EC2 for its flexible resource allocation and reputation, among other things (though EC2 differs somewhat from a VPS in how it handles virtualization, they’re similar enough here).
I created an EC2 instance, connected my domain, and put up a temporary landing page. A month or two later, the instance fee came out of my bank account. I don’t remember exactly how much it was, but it wasn’t unaffordable. Still, the thought of another monthly expense bothered me, and I wanted to avoid it if I could. That’s when I remembered the Raspberry Pis lying around my house.
They were two Raspberry Pi 3 Model B+ boards I’d picked up in my department’s student room about a year earlier. The boards were in a box with some sensors and wires, and the lid said anyone who needed them could take them. They must have been left over from a major course or side project. I hadn’t brought them home with this in mind, but they seemed perfectly suitable as servers. Their performance was bound to be lousy, but each was a complete computer. And since they weren’t particularly powerful, it would be a shame to leave them sitting unused.
As soon as the semester ended, I got to work setting up the server. There was far more to do than with EC2. With EC2, I could choose an operating system, set a few port rules, and connect remotely over SSH right away. With the Raspberry Pi, I had to do everything myself: format the SD card that would serve as its main storage, download an Ubuntu image and boot it, connect to the network, and set up port forwarding for SSH. The Raspberry Pi has no screen, and I didn’t have an external monitor, so I connected it to the living-room TV over HDMI and sat on the floor to work. It ended up behind the TV partly because the router was nearby and things there rarely got moved, but mostly because I had to do all the CLI work on the TV until I could connect over SSH.
I spent three or four days doing almost nothing else. I obtained an SSL certificate, got HTTPS working, built the Vue.js project I’d been developing locally, and uploaded it to the server. I can’t tell you how happy I was when I finally confirmed that I could access the site on my iPhone.
A screenshot I took then. The post page looks a little different now: there’s no longer a cover image or an emoji in the header.
I wanted the site to feel modern but understated. When I started developing it, I thought Notion’s design was excellent, so I exported a Notion page as HTML and copied out its entire stylesheet. I made some changes where needed, but as I built the pages while largely keeping that style, I suddenly wondered: is this really understated? The emojis that often appear on Notion pages felt youthful and fresh, but they could also be distracting. On a site centered on writing, they would make the text feel less compact. So I kept refining the pages, using emojis and images only where necessary and minimizing the use of color to preserve that understated feel.
While building the site, I also thought the design of the Chosun Ilbo website was good (regardless of politics). And when I visited New York late last year, I felt that the websites for MoMA and the Whitney Museum were aiming for something similar. Take a look at all three and you’ll probably get a sense of the look I’m after.
Actually, the development story above was supposed to go in this site’s first and second posts. But I tried to fit everything I’d learned and felt at the time into a single post, ran out of steam halfway through, and abandoned it. Only now, after forgetting so much, can I sit down and sum up the whole process in one go.
-
I might as well dump my notes on reference sources here, too
The point is that this site runs on a tiny Raspberry Pi behind my living-room TV. In other words, every time you visit gunh.ee, your request comes through my house before the response heads back to your device.
Back to today. Since the server went live, I’ve used it for quite a few things besides publishing blog posts. Above all, it’s been incredibly convenient for testing web-service deployments. Deploying something under a new domain meant buying that domain, finding a hosting service, and waiting for DNS propagation—all of which took time and money. Creating a new subdomain on gunh.ee solved all of those problems.
Today’s idea to connect the Raspberry Pi, which had been relying on WLAN, to Ethernet came to me while I was planning to test a new service on gunh.ee. Before testing a whole lot of request-response exchanges, I figured I should optimize the server’s connection.
This wasn’t my first attempt to switch to Ethernet. I’d long felt that images in my blog posts loaded too slowly. At first I thought the Raspberry Pi’s processing speed was to blame, but the more I thought about it, the more likely it seemed that image sizes and connection speed were the problem. I was uploading original, uncompressed iPhone photos several MB in size over a wireless connection—a terrible combination. Fixing the image sizes would mean setting up an automatic compression pipeline, which sounded like too much hassle, so I decided to at least try improving the connection first.
Normally, plugging in an Ethernet cable should establish a connection automatically, but it didn’t. When I ran ifconfig, the Ethernet interface wasn’t even listed. I searched all over Google, but none of the solutions worked for me. In the end, I stuck with WLAN for the time being. That was a month or two ago.
Nothing had changed, but today I felt the need to try again. I retried methods similar to the ones I’d tried before, with no progress. As a last resort, I decided to try the other Raspberry Pi that had been sitting idle (I’ll call it B). Switching was easy because all I had to do was move the SD card, which held the main storage. The problem was that I’d previously failed to use B as a server. Unlike the Pi that was running the site (I’ll call it A), B had heat sinks on its processor and Ethernet controller, so I’d wanted to use B if possible. But after booting it, no terminal appeared over HDMI, and I’d had to give up on B and switch to A.
So I was skeptical even as I plugged B in. But wait—the terminal appeared this time! Feeling hopeful, I plugged in an Ethernet cable too, and... it connected! It didn’t work right away; I tried several cables around the house before one suddenly did the trick. Unfortunately, it was the longest cable, which could have been useful elsewhere, and I’m still disappointed that I never found out what was wrong with A. But hey, who cares? It works. And now I have heat sinks too, which is even better.
Even though the storage contents were the same, switching Raspberry Pis also changed the MAC address, which may be why the device’s private IP changed from 172.30.1.20 to 172.30.1.77. That broke both SSH and HTTP access, but updating the port-forwarding settings on the router restored them immediately. Something that once would have taken me half a day to fix now makes enough sense that I can resolve it right away. Moments like this make me happy to see how much I’ve learned.
Let’s stay together a long, long time, Raspberry Pi
Subscribe to my newsletter to receive an email when a new post is published.
Next: First Love
Previous: 21st-Century Fire Gazing