X button icon

Jasmine Nackash is a multidisciplinary designer and developer intereseted in creating unique and innovative experiences.

Week #04

Nginx server set up

Quick note again as this is a longer technical assignment — I will be writing as I progress. I realize that some of my questions may get answered along the way so I'll make a list of any important questions that are left unanswered at the bottom of this post :-)

I started by following the nginx installation guide from the syllabus that referenced Digital Ocean's guide. While installing it through the command line we also had to adjust for the firewall we installed a couple of weeks ago — to allow traffic through.

I was wondering about the ports — so I get that some ports are reserved and that there some that are widely used for specific things so it's best practice to adhere to that. But if I wanted to run multiple things at the same time I would have to use more ports(?), which is fine, but would I also have to reconfigure the firewall and nginx? Last class we were all communicating over port 8080 — I assume that it's meant to represent that it is an HTTP connection and I remember 443[ ] ports are usually used for HTTPS. But so why does nginx only support two ports? Do we just send the data from whatever port we want to either one of these two? Do ports behave like namespaces where If I use anything that starts with "80[ ][ ]" it'll work as HTTP?

I kept following the guide and made a "server block":

I didn't know what domain to use. I could use my private one (like the one this blog is on) but maybe I can somehow still access this itp one since it was already connected to my virtual Digital Ocean server last semester. No harm in trying!

I was wondering about all those "::" after the "listen" so googled that and learned that it means that the server will listen to all IP addresses trying to communicate with port 80. The double colons are short for "all zeros", meaning any address. The first "listen" is allowing all IPv4 traffic, and the second "listen" is allowing all IPv6 traffic.

Moving on, setting up the server block only partially worked — the root domain address seems to work, but not the subdomain one (the version with the "www." — not sure I'm using the correct terms here). I did make sure I don't have typos but could this be something the "other side" needs to sort? Like whoever is managing the itp subdomains might need to configure some DNS record?

I then ran the log command and similarly to when we were running the firewall logs, pretty much immediately there were already some addresses there:

I... will get back to this when I do the HTTP log analysis. Might want to let them pile up a bit more.

I also ran the error log command because why not:

I did look this up and learned that it's just a notice saying that nginx was reenabled (I did that at some point) and that it is using the same sockets, which is what nginx uses to communicate with clients. "inheriting" sockets allows nginx to smoothly transition between old and new processes without dropping client connections.

/ Update regarding the root and subdomain issue

Tom helped me make sure everything is set up correctly and we changed the directory name to not include dots (".") as I did because that could cause issues but it wasn't the issue this time. It seems to be a missing DNS A record, which I have no control of so I contacted the person in charge of managing the itp.io domain to inquire further.

//Second update

Getting my "www" itp domain seems unlikely and I don't want to just keep waiting so I've decided to redo everything on my personal domain. Nothing special to report. Continuing the next steps with my new domain that has the simple html page displaying in both the root and the "www" subdomain.

Configuration & encryption

So initially I've set an A record for the root and a CNAME for the subdomain because it sounded right, like they should be "connected" and have one point to the other and the other point to the server. But for the next part it seems like I need to have two separate A records for both and I wonder why is that? Looked it up and learned that it saves a tiny bit of time, offers some redundancy, is easier to manage in some cases, and is more broadly compatible with various SSL/TLS certificate providers and HTTPS configurations, which is where we're headed. Ok...

So the instructions show the firewall should allow traffic from the following:

And what I have looks slightly different:

Though I don't think this is going to be a problem because looks like I have the important bits. But if something doesn't work properly I'll come back to this.

Configuring the HTTPS and setting SSL certificate went smoothly and everything seems to be working as it should.

I ran the certificate renewal dry run command and saw some errors:

I didn't immediately notice the errors only pertain to the itp domain and not the one I set up now, so while trying to fix it I stopped nginx because I thought the ports are needed for the renewal but then couldn't start nginx again because an instance was already running?! I eventually solved it by using killall (is this the single most important command one should know?) and restarting nginx.