DJ Molny, Brennon York, Doug Lovell

Background

Since taking over the IAC website from EAA IT in late 2011, we’ve used a cloud server from Rackspace. That server is currently running Ubuntu Linux 14.04 LTS -- meaning Long-Term Support. Each LTS version is supported for five years, meaning that the OS on our server will become unsupported in April 2019.

For reasons that aren’t 100% clear to me, Rackspace servers can’t use the Ubuntu upgrade path to install the latest OS on top of an existing system. This necessitates a clean-slate installation

Service Providers

Hosting

In the seven-plus years since IAC started running its own site, cloud service options have increased exponentially and prices have dropped significantly. Since we need to rebuild the cloud server anyway, this is a very opportune time to do a little shopping around.

Rackspace is relatively expensive, costing the club between $83 and $110/mo for two CPUs and 2GB of RAM, plus bandwidth and backups.

I think we should take a look at AWS (professional-grade, less expensive) and Linode (very inexpensive, fewer add-on services available, clunky backup/restore capabilities). Additional suggestions welcome.

Doug: I’ve tried setting-up and deploying to an AWS EC2 instance and found it maddening. The AWS permissions system, IAM, is very fine grained. So much of the setup has to be done by finding and clicking through web forms. The documentation is a labyrinth. Linode, on the other hand, is just Linux.

I don’t have skin in AWS over Linode because I’m not the one who will do it. However here are some tips about Linode which might be helpful in making your decision. It’s what I personally have had success with.

• Locking down and setting-up the server: ansible-server-setup
• Creating a backup file: https://www.linode.com/docs/security/backups/backing-up-your-data/
• Copying a backup file to an S3 bucket (yes, AWS, but just a toe vs. the whole bath): https://aws.amazon.com/getting-started/tutorials/backup-to-s3-cli/
• Linode backup service: https://www.linode.com/backups

Email

When the web server needs to send an email (password reset messages, batch run outputs, etc.) it uses the Mailgun service from Rackspace. The volume is low enough that we’ve never incurred any changes.

We use a third-party service because ever more complex anti-spam requirements make it too difficult for most organizations to successfully operate their own SMTP server. Any little discrepancy can trigger a spam filter on the recipient’s POP/IMAP/Exchange server -- rerouting our messages to a spam folder or blocking them altogether.

If we switch hosting providers we’ll need a new email service as well. Candidates include:

• Amazon SES

  • If you have an EC2 host with AWS, the first 62,000 emails are free each month, 10c per 1000 thereafter

  • Supports DKIM

• Mailgun

• Mailchimp

• Zoho (we already use them for the somebody@iac.org email accounts)

• Doug uses FastMail, which is $5/mo, secure, and easy to set up.

• Many, many others

Monitoring

Rackspace provides site monitoring at no additional charge, sending emails if the site is not reachable. If we move to another hosting provider we'll need to implement similar capability, either on their platform or through a third-party service.

DNS

We’ve consolidated all our domain name registrations and DNS records under GoDaddy.

Web Server Package

We should take this opportunity to switch from Apache2 to a more modern, lightweight web server package.

I recommend Nginx. It is widely used, easier to configure, and fast. I’ve been using it on my personal cloud server for several years; it powers Drupal, Rails, and HTML/Perl (yuck!) sites with ease.

I’m open to other suggestions, but Apache must go.

Interim Instances

• Live sites using dummy domain names, protected by HTTP Basic Authentication. (Note: It’s important that the test Drupal site’s URL be the same length as the current site, e.g., new.iac.org.)

• Practice data migration

  • Drupal files

  • MySQL databases (Drupal, IACCDB, others)

• Exercise features

Cutover Procedure

• Final data migration (including IACCDB as follows)

• Reconfigure Nginx to use the official domain names

• Remove HTTP Basic Auth

• Change DNS records

• Verify basic functionality

• Announce the switch and invite users to report problems

IACCDB migration

IACCDB runs with a mySQL database. That has to be migrated. The best procedure is to:

• Make a backup. There’s a script, `db_backup.sh` in the iaccdb directory.

• Copy the backup to the new machine

• Restore the backup (by feeding it to the mySQL console program)

• Test

And for the cutover

• Put IACCDB in maintenance mode

• Repeat the above procedure

Software to Install

Drupal

• Install the prerequisites, per: https://www.drupal.org/docs/7/install/before-installation

• Copy everything under /usr/local/share/drupal7 from Rackspace cloud server to the new cloud server (as opposed to downloading, installing, and reconfiguring Drupal from scratch)

Rails

• Use git to pull the source, from GitHub wbreeze/iaccdb, into the home directory.

• Install the Ruby environment manager, “rbenv” (not rvm).

• Use rbenv to install Ruby at the .ruby_version in use.

• Ensure the shell is using Ruby through rbenv, not the system installed Ruby.

• The rbenv installs RubyGems. Use “gem install bundler” to install bundler.

• Install application-specific gems, including Rails, via “bundle install”.

• Configure nginx with:

  • The path to Ruby (via rbenv, thus accounting for Ruby updates)

  • The path to the application installed directory.

Other Pkgs & Considerations

• Web server software (Nginx or other)

• Screen-scraper for the EAA daily member list download

  • Firefox

  • Capybara

  • Xvfb

• curl

• Cron jobs

• Phpmyadmin

• Database server, mySQL

Document, Document, Document

Let’s record all configuration steps here in the Webmaster's Guide. That should make any future upgrades easier. Our future selves and/or replacements will thank us.