Lincoln Loop

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.bashrc[1]. 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.

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

Comments

• October 7, 2009 at 11:30 a.m. #
  Brett piped up:

  With `usermod -g group username` you’re actually changing the user’s primary group. That may be what you want, but typically what people want is `usermod -a -G group username` to add them to another group (without changing any current ones).

• October 8, 2009 at 6:22 a.m. #
  Halldór mentioned:

  I’m sure he wants to change the primary group since that is the group that new files are associated with.

• October 8, 2009 at 7:15 a.m. #
  布里斯班 piped up:

  This looks like very easy to use.
  Especially for many group users.

Got something to say?