Preventing yourself from accidentally breaking production with Drush

For all the sites I maintain, I have at least a local and production environment. Some projects warrant a dev, qa, etc. as well, but for the purposes of this post, let's just assume you often run drush commands on local or development environments during development, and eventually run a similar command on production during a deployment.

What happens if, at some point, you are churning through some Drush commands, using aliases (e.g. drush @site.local break-all-the-things to break things for testing), and you accidentally enter instead of @site.local? Or what if you were doing something potentially disastrous, like deleting a database table locally so you can test a module install file, using drush sqlq to run a query?

<br />
$ drush break-all-the-things -y<br />
Everything is broken!                                    [sadpanda]<br />

Secure your servers from Shellshock Bash vulnerability using Ansible

Now that all Server infrastructure is managed by Ansible (some servers are running CentOS, others are running Ubuntu), it's very simple to update all the servers to protect against vulnerabilities like Heartbleed or today's new Shellshock bash vulnerability.

For CentOS (or RedHat)

<br />
$ ansible [inventory_group] -m yum -a "name=bash state=latest" [-u remote_username] [-s] [-K]<br />

For Debian (or Ubuntu)

<br />
$ ansible [inventory_group] -m apt -a "update_cache=yes name=bash state=latest" [-u remote_username] [-s] [-K]<br />

If you have a different method of patch management, or you need to apply the fixes manually, then this method won't apply—but for most infrastructure using normal system-provided packages, using the above commands will get the fixes with minimal effort.

A little further explanation: