Lately I've been working on a new Drupal 7 theme for the university and while trying to configure the editor we ran into a few issues with adding classes to some dom elements. Primarily we don't want middle users to be able to add any classes or other attributes that we don't want them to use. We've got a set of pre-defined classes that they can use in their content. The wysiwyg_filter module pretty much takes care of enforcing that.

I also needed to do is to provide a filter to add some classes to a few different dom elements a user might include in a page. For instance, we want to add the img-responsive class to all images a middle user adds to the site. That way they are responsive by default, and Drupal's built in input filters makes it pretty simple to set everything up.

You start with implementing the hook_filter_info() hook with some information about your filter:

There you go, you're done. After you go to your input formats page and add the filter, clear the cache, you have a filter that automatically adds the img-responsive class to all images a middle user creates.

Last Saturday I had a chance to hang out with a group of awesome Drupal folks at the Charlotte Drupal Drive In. It great chatting with everyone talking about a few tools I use on a daily basis. One thing I talked briefly talked about was how I manage my development environments and how I use Vagrant, git, and Puppet to help me keep everything in order.

First, you need to download and install Vagrant and whatever virtual machine provider you want to use. I prefer VirtualBox, but this also works with most other vm hosts. It also works with AWS and DigitalOcean.

After you have everything setup you should have the vagrant command available in your shell. The command lets you manage your VMs really easily, you can learn more about the command line interface by reading the documentation.

After you've figured out how to use the command line interface for vagrant, the next step is defining a Vagrantfile for your environment. You can either us the vagrant init command or write one yourself. The vagrant init is a decent boilerplate for building your Vagrantfile. If you clean up the commented code, you should have something like this:

This is all you need to bring up a barebones VM. We're going to make a few changes to it. If you run vagrant up you should have a VM up and running soon.

Now that we have a vagrant file, let's start to think about an architecture for our development environment. I typically like to have a VM for my web server, with the hostname web.local, a VM for my database server, db.local, and a VM for memcache. The hostname for that box is memcache.local. We'll get into why they are named like that later on when I talk about Puppet. We also need to define a network between all of these boxes, it's going to look something like this:

Because I'm on a mac I can use nfs mounts to mount the share/ and share/www to specific places on the virtual machine. For instance, if I'm working on a site on my vm, I will typically mount the share/www/docroot to /var/www/docroot on the VM, or wherever the vhost file says it should be.

This lets me keep all of my development work happening in my vim/tmux session on the host machine. Now, because I'm using git to manage my environment, I can use branches and tags to version my environment and work a lot of different tasks. It also makes it really easy to share your environment with others and bring up development boxes extremely quickly.

The final part here is using puppet and several puppet modules to maintain the software on each VM. Since we're using different descriptive hostnames on each box, we can build our puppet manifest in a way that automates deploying code to different boxes.

You're going to have to start by creating a folder structure in your repo and adding a few more config options to the Vagrantfile. First, you should add a folder for manifests and modules to your repo and create a default.pp file:

dev_env/manifests/
dev_env/manifests/default.pp
dev_env/modules/

I prefer to us git submodules to manage my puppet modules. You should be able to just add the module from within the repo like this:

I also tend to setup classes for each functional part of the puppet manifest. So, I would have something like manifests/classes/common.pp that configured my user info, some basic packages need for the box, and other random things. I would have something like this setup:

That's about it, you can configure puppet to build the VMs pretty much however you want and you can extend puppet with different modules. There are also plugins for vagrant that let you extend the functionality and a fair amount of cool things.

I've recently started using fail2ban more to ban suspicious traffic on my web servers. It's great because it looks at logs and if an entry matches a regular expression it will perform an action on the IP address from the log. You can make the actions do pretty much anything, typically the action is an iptables rule that will ban the user. The problem is when you restart the fail2ban service fail2ban clears the chain for the filter and parses the current log for matches, not the rotated logs. So you don't ban any IPs that were banned before logrotate rotated the old log.

You can make the bans persistent by setting up a blacklist and automatically loading them when fail2ban is restarted. First, you need to create a file to store blacklisted IPs.

sudo touch /etc/fail2ban/ip.blacklist

Then you can either make a copy or edit the /etc/fail2ban/action.d/iptables-multiport.conf file. I prefer to make a copy of it because I version all of my configs.

In the action config file you have a few different directives, we want to focus on 2, the actionstart and actionban. First, when fail2ban bans an IP we want to not only ban it, but we want to add the IP address to the ip.blacklist file.

Recently I had to push out a few updates to a site that required a few big interface changes that I didn't want the public to see while I was making them. The application is running under Apache and we're using Varnish 3.x as a reverse proxy.

I wanted to be able to have a white list of IPs that can access the site and be able to display a custom error page to the user letting them know that the site is undergoing maintenance. If I were only running Apache I could do it easily in the vhost for the site, but we're using Varnish so we need to stop the request once it hits the server. I could do it with iptables and block traffic to port 80 and 443, but I wanted to display a message to the end user letting them know that the site is under maintenance.

Varnish makes this really easy, all you have to do is define access control lists and populate it with the IP address of machines you want varnish to whitelist.

So, there we go, we have our acl defined with our IPs that varnish will talk to, we have our check to make sure the client.ip is able to talk to varnish, and finally we have our error message. You can put anything in there and even load it from a file if needed.