Recovering from a WordPress Hack

Last night I had the unpleasant discovery that this site’s WordPress had been “hacked”, with every post redirecting to an uploaded “this site has been hacked” variety of HTML file. I looked back and realized it happened on March 1st and mad at myself for not noticing sooner.

Fortunately it was pretty easy to clean up by zapping the database and restoring from a good backup (thankfully I have daily backups running).

The harder part is going to be recovering in Google’s view. Search queries as shown in Google Webmaster Tools dropped like crazy right away:

Search queries chart from Google Webmaster Tools
Search queries chart from Google Webmaster Tools

And here’s the corresponding crawl errors view:

Crawl Errors Chart from Google Webmaster Tools
Crawl Errors Chart from Google Webmaster Tools

Hopefully after a little time the Google crawler will see all those pages returned, but I’m guessing whatever page rank I had will be very slow to recover (if it ever does). In the meantime I’ve improved my WordPress security a bit more, updated to the latest of everything, and removed a few unused plugins. Next will be to set something up to notify me more quickly if this happens again.

DataStax Installer with Vagrant

I’ve continued to make improvements to my “Cassandra on Vagrant” project (Using Vagrant for Local Cassandra Development) which shows how to install open-source Cassandra or DataStax Enterprise in a variety of different ways. Using Vagrant is very helpful for local development and testing. Virtual images can be created very quickly and can be erased when done, keeping your primary development system clean.

Recently I added an example which uses the DataStax Enterprise (DSE) standalone installer which first appeared in DSE 4.5. The standalone installer normally runs in a graphical UI mode, but can also be run in an unattended mode which I’m using here.

To play with the examples, grab a copy of the Vagrant projects from GitHub: bcantoni/vagrant-cassandra. Once you have Vagrant and VirtualBox set up, check out example 5. DSE Installer and go through the setup.

On my Mac laptop, creating a 3-node DSE cluster takes less than 5 minutes. (The speed is greatly improved because we only need to download the installer once.) The installer has several options for running in unattended mode, so the installation can be customized as needed.

See the code and more details at bcantoni/vagrant-cassandra.

Tech Advent Calendars – 2014

It’s that time of the year again – Advent calendars for many tech communities. As in past years (2011, 2012, 2013), I’ve gathered a few here that should be interesting:

I have a combined RSS feed (created with Yahoo! Pipes) that picks up all of these advent calendars: (Yahoo Pipe source).

Creating Print Stylesheets for Other Sites

Creating a print stylesheet for your website is a nice optimization that your visitors will appreciate, especially if your site features articles that are longer or are technical in nature. Print stylesheets don’t take too much effort to create and maintain over time along with your site CSS.

But what if you’d like to have print stylesheets on someone else’s website?

Here’s an approach I’ve used to hack together simple print stylesheets that I’ve sent to other site owners as a contribution. This works very well for personal blogs and open source projects, both of whom are usually open to contributions.

Make a Local Copy

The first step is to make a local copy of a representative page from the site. For example, if the site is a blog, pick a good sample post (not the home page or an index page).

These steps require wget which already exists on most Mac/Linux systems, or can be installed for Windows.

  1. Download the sample page with wget: wget -p --convert-links URL
  2. If the downloaded file doesn’t have extension .html, rename it (e.g. if the download was index.php, rename it to index.html)
  3. Open the .html file in a local browser and make sure everything looks okay; some dynamic content such as ads may not appear correctly, but that’s okay
  4. Edit the .html file and after all the other CSS includes, add reference to a new local file: <link rel="stylesheet" href="print.css" media="all" />
  5. Create the print.css file and start with something that will be obvious like: p {color:red;}
  6. Refresh the .html file in the browser and make sure the local print.css is being picked up

Create Print Stylesheet

Now we’ll go through and build up print.css to hide and adjust content sections as needed to create a good looking printout. For this step I usually use Chrome or Firefox with their built-in Inspect Element features. You can make iterative changes to the print.css and refresh in the browser.

Hide Sections

Find all sections/divs that are not the content. This will typically be the header, footer, sidebar, ads, comments, and so on. You’ll need to adjust your CSS selectors depending on the content, starting with the most general and working down as needed.

For each section identified, set it to display:none. For example:

header, footer, div#leftnav {
    display: none;

Adjust Widths

Most site designs will have a hierarchy of <div> elements which result in the main content being narrower than the full page. We want to adjust that out to 100% to be more appropriate for a printout. A good starting point is the following:

div#content, #main {
    width: auto;
    max-width: 100%;
    float: none !important;

Adjust Fonts

You might need to adjust the font settings, particularly the size. There is also the question of serif vs sans-serif and which works better for print. (You choose.) You may also need to reduce font size and margins for heading elements <h1>, <h2>, etc. if they are being printed too big.

For example:

div#content, #main {
    font: 11pt Georgia, "Times New Roman", Times, serif;
    line-height: 1.3;


Depending on the site content, here are some other things to consider:

  • Hide any embedded video objects like YouTube
  • Hide comments/discussion
  • Set color to black on white background
  • Add URLs after <a> links

Contribute Back to Site Owner

Once you have your print.css file ready to go, I suggest adding comments to clarify the different changes you made. That way, the recipient can better understand what you’ve done, and make selective changes if they want.

Send the file to the site owner as a .txt file, or via a service like pastebin. They can use your contribution either as a standalone print stylesheet (<link rel="stylesheet" href="print.css" media="print" />) or directly inside an existing stylesheet at the end (@media print { ... }).

Good luck. If you use this technique and are successful in creating a print stylesheet for someone else’s site, let me know!

Quick Guide to Vagrant on Amazon EC2

Here’s a really quick guide to using Vagrant to create virtual machines on Amazon Web Services EC2. I’ve gotten a lot of use out of Vagrant for local development, but sometimes it’s helpful to build out VMs in the cloud. (In particular, if your local machine isn’t very powerful.)

These steps assume you already have Vagrant installed and have an Amazon Web Services account (and know how to use both).


First you’ll need to install the Vagrant AWS plugin:

vagrant plugin install vagrant-aws
vagrant box add dummy

Next login to your Amazon AWS console to get a few things:

  • AWS access key
  • AWS secret key
  • SSH keypair name
  • SSH private key file (.pem extension)
  • Make sure the default security group enables SSH (port 22) access from anywhere

I like to set these up as environment variables to keep them out of the Vagrantfile. On Mac or Linux systems you can add this to your ~.profile file:

export AWS_KEY='your-key'
export AWS_SECRET='your-secret'
export AWS_KEYNAME='your-keyname'
export AWS_KEYPATH='your-keypath'


Now we can configure our Vagrantfile with the specifics needed for AWS. Refer to the vagrant-aws documentation to understand all the options. In the example below we have all the AWS-related settings in the x.vm.provider :aws block:

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.define :delta do |x| = "hashicorp/precise64"
    x.vm.hostname = "delta"

    x.vm.provider :virtualbox do |v| = "delta"

    x.vm.provider :aws do |aws, override|
      aws.access_key_id = ENV['AWS_KEY']
      aws.secret_access_key = ENV['AWS_SECRET']
      aws.keypair_name = ENV['AWS_KEYNAME']
      aws.ami = "ami-a7fdfee2"
      aws.region = "us-west-1"
      aws.instance_type = "m3.medium" = "dummy"
      override.ssh.username = "ubuntu"
      override.ssh.private_key_path = ENV['AWS_KEYPATH']

See this Github gist for a longer example file.

Now you can bring up the VM by specifying the AWS plugin as the provider:

vagrant up --provider=aws

After about a minute, the VM should be up and running and available for SSH:

$ vagrant up --provider=aws
Bringing machine 'delta' up with 'aws' provider...
==> delta: Launching an instance with the following settings...
==> delta:  -- Type: m3.medium
==> delta:  -- AMI: ami-a7fdfee2
==> delta:  -- Region: us-west-1
==> delta:  -- Keypair: briancantoni
==> delta:  -- Block Device Mapping: []
==> delta:  -- Terminate On Shutdown: false
==> delta:  -- Monitoring: false
==> delta:  -- EBS optimized: false
==> delta:  -- Assigning a public IP address in a VPC: false
==> delta: Waiting for instance to become "ready"...
==> delta: Waiting for SSH to become available...
==> delta: Machine is booted and ready for use!
==> delta: Rsyncing folder: /Users/briancantoni/dev/vagrant/aws/ => /vagrant

$ vagrant ssh
Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-29-generic x86_64)



  • You need to configure a specific AMI for Vagrant to use. I find the Ubuntu Amazon EC2 AMI Finder very helpful to match the version and region I wanted to use.
  • A common tripping point is the default security group not allowing SSH (port 22) from any IP address. Also make sure to add any other ports depending on your application (e.g., port 80 for HTTP).
  • Once you have the basics working, make sure to read through the vagrant-aws project to understand all the options available.
  • Make sure to vagrant destroy your VMs when done, and check the AWS Console to make sure they were terminated correctly (to avoid unexpected charges).