Website Hosting with Custom Domain Name

We were asked to host a site for a student group, and it happens they had a domain they wanted to use. Forwarding wasn't enough: they wanted the site to not appear as if originating from cs.earlham.edu. This is the guide.

Note: This guide will be updated when we resolve some issues with SSL.

Assumptions

We assume you're running this on CS, which uses Apache as the web server. The instructions will be different in places running nginx. This also assumes familiarity with the terminal, bind/DNS, and basic networking.

Also, have the following information at the ready:

• the IP address of your web host - as an example, we'll use 192.0.2.1, as per the rules
• the domain name - we'll use example.com

Domain: Replace the DNS records.

You'll need to replace the DNS records - which indicate which IP address your domain should point to - with your own.

First delete the old hosts. (If you need to backtrack, it's usually not hard to reset to the default hosts later.)

Add two A records:

• hostname @, 192.0.2.1
• hostname www, 192.0.2.1

I used Hover's default 15 minute TTL, but (as we millennials say) you do you.

No need to worry about the name servers.

Add to /etc/hosts

Add a line to /etc/hosts on the web server (e.g. web.cs.earlham.edu) reading as follows:

192.0.2.1 example.com

Or append example.com to the existing line for your IP address.

Add to Bind

In /etc/bind/yourdomain.zone, add the CNAME:

example      IN     CNAME   web.cs.earlham.edu.

Run service bind9 restart or your OS-specific service manager to update the bind configs.

Create a VirtualHost on Apache

In your available sites path, in our case /etc/apache2/sites-available, copy the default (000-default.conf) file to a new file for your site:

cp 000-default.conf example.com.conf

Edit as follows:

ServerName example.com
ServerAlias www.example.com
DocumentRoot "/path/to/your/content/or/cms"

The DocumentRoot portion is where you might point to, say, a WordPress directory or a group of publicly-accessible user files. The nice thing about this is that it's somewhat modular: these steps apply to CMS systems in general, not just WordPress as in our use case.

If you want, you can also do specific configuration edits here - for example, I put the error log in a separate directory when testing this.

Run a2ensite example.com to activate a site with the configuration you've provided.

Run service apache2 reload or your OS-specific service manager to refresh the Apache settings.

So:

a2ensite example.com
service apache2 reload

Verify or Fix

Check example.com!

If it didn't work, retrace your steps carefully. Check for typos, skipped steps, etc.

A note about iterative development and DNS

To grossly oversimplify, a lot of programming involves fast iterations: make some change, check if it worked, if so great, else repeat with a new change. DNS frustrates that workflow because you have to wait for DNS changes to propagate. If you're getting inexplicable results at some point, propagation is probably the reason. Give it time. If a long wait is bugging you, check the URL on a different computer than your usual workstation.