Migrating a Vagrant VM into Qubes as StandaloneVM

I had a Vagrant VM on my other laptop that I wanted to convert into a Qubes AppVM (StandaloneVM).

The disk was lazy allocated 40GB but only using about 1.3GB within the guest.

The underlying disk of the Vagrant VM was a .vmdk. A lot of guides online talk about compacting VDIs, but I had to convert my VMDK first, I couldn't compact it directly.

Here's how I got it into Qubes.

Terraform remote state and errors about AWS_DEFAULT_REGION

This may be obvious to others, but it wasn't to me.

I was setting up Terraform remote state storage (to an s3 bucket) like so:

terraform remote config -backend=s3 \
           -backend-config="bucket=mig5-terraform-state" \

I kept getting the error on the above:

Failed to read state: Error initializing remote driver 's3': missing 'region' configuration or AWS_DEFAULT_REGION environment variable

This worked, of course:

Deploying and managing Autoscaled Drupal applications at AWS with Terraform, Packer and Fabric

As part of a prototype/experiment for a customer, I decided to 'eat my own dogfood' and put this site onto an autoscale cluster at AWS.

In doing so, I wanted to manage my infrastructure using Terraform (a configuration management tool). In addition, since the use of autoscale requires using a base image (AMI) capable of hosting the site, I wanted to build the AMI using Packer. Furthermore, I wanted to use Puppet to speed up that configuration of the AMI built by Packer.

'Nice to have' goals

I had a few other goals also in mind:

Source based load-balancing in HAproxy based on X-Forwarded-For header

We had some application servers behind an active/passive HAproxy loadbalancer pair (using keepalived to arbitrate the IP on failover).

We needed to put a WAF product in front of the HAproxy pair (e.g Sucuri's CloudProxy or CloudFlare). This might seem odd to put a reverse proxy in front of a HAproxy pair (yo dawg, I heard you like proxies), but we need to do some funky extra munging of URLs and the like via HAproxy configuration rules, which upstream providers can't account for.

mig5 in another BetterCloud article about communication and I.T

As a separate piece to the previous three part series published, I was featured in another BetterCloud article about elevating the perception of I.T teams in the wider parts of organisations.

This builds again on my belief that the combination of communication and the right toolsets makes all the difference.

Interview with BetterCloud about I.T and communication

I was one of three professionals recently interviewed by BetterCloud for a series on blending the art of effective communication into I.T (with a focus on communicating to people in a less-technical role). This includes not just supporting end-users but communicating 'above' to C-level type management, trying to get budget buy-in for a project, and so on.

The series covers tips on how to do this effectively, as well as some pitfalls to avoid.

Caching both HTTPS and HTTP Drupal sites behind HAproxy and Varnish

Scenario: you have a Drupal site behind a proxy such as HAproxy, sending traffic to a Varnish backend (which in turn sends to the Nginx or Apache backend).

You want to serve cached pages from Varnish for both HTTP and HTTPS. Perhaps you've tried this and you found that behind HTTPS, your site had no CSS or JS. This is because it's serving a page object that was cached as HTTP, or it's not caching at all, but Drupal is serving the markup with http:// links and your browser won't allow that to be displayed under https:// .

Yubikey 2FA on Qubes redux - adding a backup key

Previously I wrote about adding Yubikey 2FA authentication in Qubes (not for using Yubikey on remote sites, but on 2FA of your Qubes system itself), explaining a couple of the differences in my technique compared to the official docs (e.g I don't believe in backdooring with a password in absence of your Yubikey, especially since with a usbVM, that VM can read the password as you type it!