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
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.
1Thanks to Vlada Macek for the tip on /etc/bash.bashrc.