bavatuesdays

I’ve been on a server admin crash course over the last 8 months or so, and I’ve been thoroughly enjoying myself. I have been fortunate to have the most patient and generous teacher I’ve ever studied under: the great Tim Owens. I truly have a deep respect for how much he has taught himself over the last 4 years, and trying to catch up with him gives me an even deeper appreciation of his mad skills.

One of the turning points for Reclaim Hosting this semester has been taking on large-scale WordPress Multisite instances for institutions. We jumped in with both feet when we took over the hosting of VCU’s Ram Pages—a beast I have written about recently. Tim did a brilliant job scaling this extremely resource intensive WordPress Multisite, and I was eager to try my hand at the setup. Luckily Reclaim has no shortage of opportunities, and recently the University of North Carolina, Asheville was interested in experimenting with a pilot of WordPress Multisite, so I got my chance to work through the setup with a brand new install.

This setup has a few moving parts, and I will take you through them in detail below, but one of the most exciting pieces of this setup—at least for me—is the fact it was built on top of a script created by someone else for a Linode server stack. Such recipes/setups scrips are called StackScripts, and they point to the real possibilities of creating flexible, custom server environments using virtual servers. This world is new to me, but the more I learn about it the more I am convinced we are on the cusp of making managing personal server architecture, infrastructure, and maintenance as easy as Web 2.0 made personal publishing on the web. I’ll be talking about this at length in just a few days at OER16, so we’ll see how that argument goes 🙂

As for this WordPress Multisite setup, we built on top of this StackScript by blueprintmarketing, which uses Nginx (an alternative to Apache), Varnish (HTTP caching), Memcached (memory caching), PHP5 fpm, and MySQL, This combination of technologies is optimized for heavy load WordPress sites, and it highlights the custom environment possible when rolling up a customized virtual server environment. What’s more, someone much smarter than me figured it out, and provided a script to make it easier to piggyback on their hard work. That’s pretty awesome, and I can’t imagine StackScripts (or AWS’s equivalent Amazon machine Images) like this wouldn’t be invaluable to individuals and institutions alike.

Installing a StackScript through Linode

In terms of the install, it really couldn’t be easier on Linode. You setup a virtual server, in this case running the Ubuntu 14.04 operating system. After that, you click on the Rebuild tab in the server’s dashboard—underneath and to the right of the configuration profile.

Once you click eebuild you will get the following screen, click on the “Deploying using StackScripts” link to the right of the server options:

From there you will be given a series of options to fill out, such as server’s hostname, username, password, etc. Your public ssh key is often named id_rsa, but you may want to make sure of that, or read this to learn how. If you are scrathcing your head about your server’s hostname, this is usually the name you assign the IP address. For example, in AWS’s Route 53 I pointed the server’s IP at personalapi.reclaimhosting.com (papi.reclaimhosting.com would have been shorter and easier, but you live and learn). The rest of the field refer to the domain you will run the WordPress on (in this example personal-api.com), WP username, password, admin email, MySQL details, etc.

After that there will be the details for your server:

You should be good to rebuild the server at this point. And once you do and the new setup rebuilds, you will need to Reboot the server in order for the changes to take effect.

Setting Up DNS

At this point you might also want to point your domain to the server. I needed to do a few things at Reclaim for this, so I figured I would share. I had to edit the DNS and setup an A Record to point my domain (personal-api.com) at the IP address as well as, as well as a wildcard A Record, or *.personal-api.com.

The other thing I needed to do is point the domain to nameservers besides ns1.reclaimhosting.com and ns2.reclaimhsoting.com, which are specific to our cPanel servers. I had no ideas about this one, so it was totally new to me. I had to point the nameservers for my domains to ns3.reclaimhosting.com, ns4.reclaimhosting.com, ns5.reclaimhosting.com, and ns6.reclaimhosting.com.

After that, you should have a WordPress instance running on your Linode server with a custom setup built to withstand heavy loads.

Customizing the Setup

In this setup, the WordPress install is located within var/www/wordpress

But there are a few customizations to be done. First and foremost, you need to make the instance a WordPress Multisite because out-of-the-box this is a single WordPress site. This is a fairly simple process, just follow these steps to allow the multisite and install the network. One difference you will find is there are no .htaccess rules you need to add given you are running Nginix. But you do need to copy and past the details into the wp-config.php file once you have created the network.

Pro tip: as a security measure, the admin for this application on the server is not allowed to be root. You can sudo su as root, and Tim pointed me to this tutorial for making it so you can sudo su once you’re logged in as the user to make root level changes as needed.

Nginx Customizations

Next up, you will need to edit the nginix configuration for this WordPress site:

nano /etc/nginx/sites-enabled/wordpress

Once you open the file, you need to add the following lines:

    index index.php;
    port_in_redirect off;
    set_real_ip_from 127.0.0.1;
    real_ip_header X-Forwarded-For;

     client_max_body_size 100M;

It should look like this:

These lines will make sure that logs show the real IP addresses rather than 127.0.0.1, as well as increase upload sizes for files to 100 MBs.

Varnish Customizations

There are two other things we need to change in Varnish. The first to add a few lines to manage timeout issues. Edit the following file:

nano /etc/varnish/wordpress.vcl

From there, and the following three lines near the top:

    .connect_timeout = 3.5s; # Wait a maximum of 1s for backend connection (Apa$
    .first_byte_timeout = 60s; # Wait a maximum of 5s for the first byte to com$
    .between_bytes_timeout = 60s; # Wait a maximum of 2s between each bytes sent

It should look something like the following:

And while you are in the file you need to make one more change. Delete the following lines:

if (req.url ~ "^/$") {
        unset req.http.cookie;    
    }

The save and exit the file, and run:

service varnish restart

Setting Up Email 

The final piece for me was setting up email for this WordPress Multisite isntall. I used this awesome tutorial from Digital Ocean to setup Postfix on my Ubuntu server. Postfix is a free, open source mail transfer agent, and it gets the job done quite nicely. The only additional thing you may need after setting Postfix up on the server is an SMTP service to send the mail. We recently moved to Sparkpost for this, and once you verify your domain using DNS TXT records, you get an API key and add the settings to you Postfix configuration file. You can find a good tutorial for these settings here.

And I think that’s it. I write a post like this as a tutorial for myself because I know I’ll come back to it again and again because I can’t remember shit. And there is always the off-chance someone else out there needs the level of explanation I do, though I imagine most sysadmins wouldn’t need anything quite this pedantic. All I can say is: ONE DAY!