Primary image for Easy Fabric Deployment, Part 2: Multiple Committers and the Dreaded Umask

Easy Fabric Deployment, Part 2: Multiple Committers and the Dreaded Umask

In part 1, we showed how we use Fabric to update and deploy Django sites to our development server with a single command. This works great when you only have one developer pushing changes to the server, but what happens when multiple committers need to update the development server?

Linux File Permissions

Typically, the default permissions for newly created files are readable by everyone and writable by the owner (644 or -rw-r--r--). These permissions are determined by the processes umask, with the default being 022. Since we want multiple committers to be able to write to files on our development server, we need to change that to 002, creating group-writable files (664 or -rw-rw-r--).

The standard way to do this is to add the line umask 002 to /etc/profile. While that works great for interactive shells, it does not get called on *non*-interactive shells (the kind that Fabric uses). To change the umask for non-interactive shells, simply add umask 002 to /etc/bash.bashrc1. Note, however, that /etc/bash.bashrc returns early on non-interactive shells, so it must be inserted before these lines:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

Linux User Groups

Most (all?) modern Linux distributions create a new group for each new user, so even though we have the umask set correctly, none of our users will be in the same group by default. We’ll start by creating a new group, then adding users to the group we created. That process looks like this:

# addgroup devs
# adduser --ingroup devs username
If the user already exists on the system, you can change its group like this:
# usermod -g devs username
Once the umask is set and all the committers belonging to the same group, everyone can update the development server via a single command. As mentioned in the previous article, this could also be accomplished with some post-commit hooks or a simple cron job to update the repo on a regular basis. One of the benefits of this setup is that committers have access to the server if they need to perform one-off tasks such as loading or dumping fixtures. For non-production servers with trusted committers, we’ve found this to be our favorite setup. Note: This article is Ubuntu specific and file locations and commands may vary based on your distribution.

1 Thanks to Vlada Macek for the tip on /etc/bash.bashrc.

Peter Baumgartner

About the author

Peter Baumgartner

Peter is the founder of Lincoln Loop, having built it up from a small freelance operation in 2007 to what it is today. He is constantly learning and is well-versed in many technical disciplines including devops, …