hosting an nginx http reverse proxy in a debian vm - part 1 - resource by hostname

prereqs

I’m starting with a fresh console install of debian 8, running on kvm using bridged networking.
My test url is doom.mogness.net, which I’ve instructed my DNS to point back at my NAT router.
I’ve configured my NAT router to point to the new VM at port 80.
I’ve installed the following additional packages and their dependencies using aptitude

  • libpam-ssh – for ease of access to my new server (not required)
  • tcpdump – to monitor the tcp activity on my new server (not required)
  • vim – my editor of choice (not required)
  • nginx – the magical reverse proxy (required)

now I can watch any traffic to doom.mogness.net hit my VM and return the nginx “I’m working page” which lets me know I’ve got the network setup correctly.

nginx welcome

configure environment

Now, without really knowing whether or not nginx can do this, I’m going to try and get it to serve a simple http file for now. As luck would have it, nginx’s beginner’s guide describes something just like that.

nginx is configured to run under user www-data by default, so I’ve created a path that nginx can access on the vm “/data/www” giving the group www-data ownership
chown -R :www-data /data
and giving that group write access to the path.
chmod -R g+rw /data
finally, I’m adding myself to the www-data group so I can modify the contents without being root
adduser mog www-data

create a simple test file

I’ve authored the following glorious index.html to be served at doom.mogness.net for starters:

<html>
<head>
<title>Mogness DOOM Server Status</title>
</head>
<body style='background-color: black; color: white; font-size: 12px;'>
<p>Running on <b>Doomsday</b></p>
</body>
</html>

configure nginx

I found my way to /etc/nginx/sites-available and copied the default file for safekeeping before replacing it with the following very basic config file:

server {
listen 80;
listen [::]:80;

server_name doom.mogness.net;

root /data/www;
index index.html;

location / {
try_files $uri $uri/ =404;
}
}

test basic config

now, according to the documention, I should be able to just run
nginx -s reload
and be off to the races. let’s give it a go.

doom.mogness

well I’ll be damned, works just like that. Good deal.

hostname-based configuration

before I wrap up part one, I’d like to see if I can get a different hostname to return a different page when when targeting this machine. with a little configuration I should be able to get nginx to serve up something else. a few steps here I’m skipping over:

  • point a new subdomain (home.mogness.net) to the same NAT router.
  • create a cheezy html file to test /data/wwwhome/index.html

the key here will hopefully be the updates I’ve made to the nginx default config. I’ve added a second server section that serves home.mogness.net from a different directory that doom.mogness.net. It now looks like:
server {
listen 80;
listen [::]:80;

server_name doom.mogness.net;

root /data/www;
index index.html;

location / {
try_files $uri $uri/ =404;
}
}

server {
listen 80;
listen [::]:80;

server_name home.mogness.net;

root /data/wwwhome;
index index.html;

location / {
try_files $uri $uri/ =404;
}
}

so, let’s see if it works. first reload nginx
nginx -s reload
and this time let’s hit home.mogness.net
home.mogness

brilliant. just works. after verifing that doom.mogness.net is still returning the expected page (it is) we can see that nginx gives us flexibility at the top level to serve via the hostname, abstracting the difficulties of doing this ourselves. the next article in this series will start attempting to unwrap the true power of nginx by directing requests to actual servers instead of static files.

PHP Support For Visual Studio

What? Really? Unless my eyes deceive me, we’ve had a PHP plugin for Visual Studio since November.

It’s got pretty good reviews as well. You can bet I’ll be looking at this in the very near future.