System Overlord

A blog about security engineering, research, and general hacking.

Managing Drupal with Git

For a while now, I've been meaning to manage my Drupal site (and the modules and features on it) with git.  The release of Drupal 7.7 provided a perfect opportunity to make this transition.  I've now cloned the main git repository, added my features (as submodules) and added the modules I use (also as submodules).  I'm still getting used to working with git, and I wish there was a way to push parts of my configuration remotely, but I understand why you can't.

If anyone is wondering, the following modules are used on this site:

  • APC
  • Boost
  • CKEditor
  • Context
  • CTools
  • ELFinder
  • Entity
  • Features
  • Field Group
  • Geshi Filter
  • Git Deploy
  • Google Analytics
  • Gravatar
  • Libraries
  • Link
  • Linkit
  • Media
  • Panels
  • Pathauto
  • Pathologic
  • ReCaptcha
  • Redirect
  • Secure Login
  • Secure Pages
  • Strongarm
  • Styles
  • Token
  • Views

Automatically Creating Archives from Git Tags

At work, we've been moving all of our development processes to git. As part of that, I've encouraged that alphas, betas, and releases be tagged in git -- it's important to know which versions are in use where. Additionally, my director wanted archives (zips/tars) of each of these versions to make it easier to install the releases, particularly for the members of our department who are not git-friendly. I realized that with git hooks and our use of gitolite, we could produce automated archives when tags with the words alpha/beta/release are pushed to the gitolite server. The script below is placed in the $GL_PACKAGE_HOOKS/common directory. It uses the name of the repository to decide if it should be archived (matches $ALLOW_ARCHIVE) and where the archive should be put (within $ARCHIVE_DIR).

# post-receive gitolite hook to produce archives
# Debug mode
# Where to put archives
# When to allow archiving (regex)
# Check if this repo can be archived
if [[ ! "$GL_REPO" =~ $ALLOW_ARCHIVE ]] ; then
    [[ $DEBUG ]] && echo "Archiving for this repository is disabled." 
    exit 0
# Get repo name
while read rev1 rev2 ref ; do
    if [[ ! "$ref" =~ ^refs/tags ]] ; then
        [[ $DEBUG ]] && echo "Not a tag reference..."
    # Get tag name
    # Check if tag contains alpha, beta, or release:
    if [[ ! $tag =~ (alpha|beta|release) ]] ; then
        [[ $DEBUG ]] && echo "Not alpha/beta/release"
    # Ensure directory exists
    mkdir -p ${ARCHIVE_DIR}
    # Repo base name
    # Make archive
    [[ $DEBUG ]] && echo git archive --format=zip --prefix=${REPO_BASE}/ -o "${ARCHIVE_DIR}/$" $ref
    git archive --format=zip --prefix=${REPO_BASE}/ -o "${ARCHIVE_DIR}/$" $ref

Avenue Q

Last night, Ann and I attended a local performance of "Avenue Q" at the Horizon Theatre Company with some people from my work.  I wasn't sure what it would be like, but the 175-seat theater is a perfect setting.  We got there just before showtime, so got seats in the very back, but even those seats have a great view.  The entire theater can only be described as an intimate setting.

While I was familiar with a few of the songs in Avenue Q, I had no idea how well the play would click with my sense of humor.  It was, without a doubt, the funniest thing I have ever seen.  I never thought I would say that I empathized with puppets, but I did in Avenue Q.  The performers at Horizon were incredibly talented and passionate professionals who put on a truly top-notch show.  If you've wanted to see Avenue Q, I can't recommend enough checking out Horizon before the show ends July 3rd.

Southeast Linuxfest 2011

This year was my 2nd Southeast Linuxfest (I'd previously attended the inaugural SELF at Clemson in 2009) and I was blown away by how it has grown.  As a former organizer for the Atlanta Linux Fest (which I terribly miss) I know how hard it is to make an event like this a success.  I have to applaud the organizers of SELF, even if I'm not sure who all of them are!  The conference retained a great "local" feel while still attracting a diverse group of people.

The Good

Most of the conference qualifies as the good -- or maybe it should be the "great"!  The speakers were engaging, seemed well prepared, and there was a wide variety of topics being covered.  I stuck mostly to the System Administration track, but I look forward to some of the others when they hit  It seemed like there was something for everyone.

I really liked the range of exhibitors as well -- everyone from Linode to Sudo Make Coffee.

The afterparties sponsored by Rackspace and were great fun, and I have to give mad props to Int80 from Dual Core for his performance Saturday night.

The Bad

I was shocked that the EFF and FSF weren't represented, and I was hoping to see Debian and Ubuntu presence as well.  Obviously, the SELF organizers aren't responsible for getting these organizations there, but I was surprised by the absences.

I also feel that SELF may be outgrowing the hotel in Spartanburg.  The aisles were crowded with attendees and vendors and it felt like so much could've been done with a little more space, but maybe this was just a matter of perspective.

The Ugly

Honestly, not much qualifies as "ugly" about SELF.  The only thing I can think of is the lack of local dining establishments in the area immediately surrounding the hotel.  There were a couple of places down the road (including a surprisingly good Thai establishment and a surprisingly bad deli) but nothing immediately "next door".


Personally, I'd like to SELF as a slightly longer event.  With the length that SELF currently is, I felt like I "had" to be in a session constantly, or I'd be missing important time.  With a slightly longer event, that sense of urgency diminishes.

I'd also like to see better use of the SELF wiki or some other resource for organizing BoFs in advance.  Having an idea of what people are interested in might help indicate if a BoF will be a success (and what time the BoF should be held.)

I wish SELF the best of luck (even if I wish we still had a successful event in Atlanta) and I hope to see everyone back next year!

Software Patent Trolls Should Die

Software patent trolls -- companies whose primary source of revenue is derived from suing others over their patent portfolion -- pose a significant risk to continuing innovation in the United States.  In order to promote future development and innovation, we need to eliminate software patents. 

At a minimum, companies should not be allowed to retain rights to a patent unless they continously produce a product that utilizes their patent.  Much like a trademark, patents not being used should fall into the public domain.

Ideally, software should not be patented.  Patents are directly against the spirit of the internet, of interoperability, and of working towards better products.  Patenting software and preventing others from developing similiar software says "I've done the bare minimum, and know I can't compete in a free market."

Software patents (like most government actions these days) favor large corporations, hamper development and innovation, and strangle Free software.  In doing so, we are continuing to set a track for countries like China and India to pass the United States as leaders of technological development.