April 6, 2005 Edition

by Adam Israel (mailto:stone@arstechnica.com)

Welcome to another edition of Linux.Ars. We've been pretty busy here in the Orbiting HQ, preparing for the launch of Ubuntu Hoary this week. Our crack staff has still managed to assemble a top-notch volume of tidbits from around the Linux world.

In this issue we are taking a look at how to extend version control to automatically deploy your projects. We'll also be throwing away those extra peripherals and learn how to controlling multiple computers with a single keyboard and mouse. We're also taking a look at new ways of exploring our musical horizons. Fasten your seatbelt, young grasshopper. We're going for a ride.


Developer's Corner


Automating deployment with Subversion (SVN)

One of the challenges I've run across as a developer is automating deployment. As a freelance programmer I want the flexibility to work from where ever the tide takes me, be it the local wifi-equipped Panera Bread or my basement office. A version control system is a good solution to that problem. I had used CVS before and was comfortable with it but I found something while reading Version Control with Subversion (http://svnbook.red-bean.com/) that made up my mind: hooks (http://svnbook.red-bean.com/en/1.0/svn-book.html#svn-ch-5-sect-2.1).


Here's the scenario: I'm building a website. I have two web servers: one for development and one for production. I want my changes to immediately replicate to the development server so that once I'm satisfied that everything works I can push the changes to production, all with a minimal effort.

For the sake of this discussion, the development web is stored under /var/www, and the Subversion root is /var/lib/svn.


Hooks are scripts that are run at various stages of the commit process. This allows you to add programmatically control, cross-reference, tweak, reject or otherwise manipulate content that is being committed to your respository. This flexibility allows you to send change notifications via email, restrict commit access by module and user or, as I'm using it, to automate the deployment of changes to a development site.

Subversion implements five types of hooks:

Making it work

The process is fairly painless. On the development server, I check out my website from Subversion. This, particularly when adding an existing project to Subversion, allows me to make sure that i have a complete working copy under version control. Next, I add a post-commit script on my Subversion server. In my case, subversion is on the same server as the development website but this can easily be adapted to work with seperate machines.

Subversion executes hooks as the user who owns the process accessing the Subversion repository. In order to allow our hook to update the development site, it needs to run with the permissions of the owner of /var/www.

There are a few different ways you can do this:

Setuid binary

Unix doesn't allow scripts to be made +s, so we can create a small C application to run svn update. Be warned that setuid binaries can be a security risk so it might not be the wisest solution for your environment.


#include <stdlib.h>
int main(int argc, const char *argv[])
  system("/usr/bin/svn update /var/www/");

Compile and set the permissions on our binary:

gcc update-dev.c -o /usr/local/bin/update-dev
chown root:root /usr/local/bin/update-dev
chmod +s /usr/local/bin/update-dev


Passwordless sudo

Another way of running svn update is via passwordless sudo. This is relatively secure if you properly configure sudo to only allow the subversion user to run svn.

Fire up visudo or (for the brave) edit /etc/sudoers:

svnowner ALL = NOPASSWD:/usr/bin/svn update /var/www


sudo /usr/bin/svn update /var/www

This allows svnowner, the user that runs the subversion daemon, to execute svn with escalated privilages -- allowing it to only update /var/www.

Group Permissions

You can use group permissions to allow the subversion user to update /var/www directly. I created a src group, added my svnowner user to the group, and changed the group ownership on /var/www to src:

chgrp -R src /var/www


/usr/bin/svn update /var/www


Make sure that the post-commit script is executable:

chmod +x /var/lib/svn/hooks/post-commit

Find out the revision information for your module:

$ svn info /var/www
Path: /var/www
URL: svn://localhost/website
Repository UUID: cecfc04c-2ff3-0310-a1e0-8517ed138fb1
Revision: 87
Node Kind: directory
Schedule: normal
Last Changed Author: stone
Last Changed Rev: 87
Last Changed Date: 2005-04-01 21:43:49 -0600 (Fri, 01 Apr 2005)

The easiest way I've found to test that this is working is to watch the revision numbers. Commit a change to the svn repository and then verify that the revision incremented on your development site.


With this in place, any changes committed to Subversion will be reflected on your development site. You could take this a step further and automate deployment to a live site, but I wouldn't recommend it. It's best to make your changes to the development site, run through QA or unit tests or whatever kind of testing you do, and then deploy to production. You can use the same tactic of making production a checkout of your svn repository. That way updating production is as simple as running svn update.

Tools, Tips, and Tweaks


Synergy (http://synergy2.sourceforge.net/index.html) is a cross-platform application that allows you to control multiple machines using a single keyboard and mouse.

It also synchronizes your clipboard and screen savers, effectively giving you one potentially large multi-platform desktop. Move your mouse off the edge of the screen to switch between displays.

There are other applications that work with similar results, such as x2x and x2vnc but I've found synergy is extremely easy to setup and works better than I could have hoped for.

Synergy is composed of two applications: synergys and synergyc. Synergys is the server portion that runs on the machine with the keyboard and mouse you want to use physically attached.

A simple configuration file, either /etc/synergy.conf or ~/.synergy.conf, defines your "screens" and their relation to each other.

My synergy.conf:

section: screens
                meta = alt
section: links
                left = ratbat
                right = gimli
                up = moradin
                left = gimli
                right = ratbat
                up = moradin
                up = smeagol
                left = smeagol
                right = frodo.local
                up = moradin
                left = frodo.local
                right = smeagol
                up = moradin

Pretty simple so far. Frodo.local, which is a Mac Mini running OSX, needs to have it's Apple key remapped in order for keyboard shortcuts to be useful using my Model M keyboard. Moradin, which is a laptop and not always connected to synergy, is set in the up position from any display. When a display is not connected to the server, your mouse just won't flip to that screen.

Connecting the client machines is easy:

$ synergyc smeagol

Performance is pretty solid. Mouse action on remote displays is pretty smooth, unless the system is under a heavy load. OSX support is considered incomplete, so your experience may differ from mine. I've only used OSX as a client and I've heard from others that have had poor performance using OSX as the server. You have been warned.

The joyous last step is to automate (http://synergy2.sourceforge.net/autostart.html) the synergy startup, so you never need to touch those other keyboards again.

Cool App of the Week

We have a dual scoop of loving this week, as we take a look at the music player amaroK and follow up on our last issue and take a look at NX.


While the world of music players for linux mostly revolved around xmms and rhythmbox, these programs stemmed from their closed-source counterparts Nullsoft's WinAmp (http://www.winamp.com) and Apple's iTunes (http://www.apple.com/itunes) respectively. Recently, a new take on the subject has led to nodding heads. AmaroK is a end-all solution for playing music in linux. Written to run off the KDE libraries, amaroK delivers in the ares of feature set, speed and configurability.

Although the features are too long to list here, some of the notables that might impress are:

The interface is clean, and by default it looks like a well-thought out KDE application. While it closely resembles JuK, another media player for KDE, most users will find the layout appealing. If not, the layout is
fully scriptable (http://amarok.kde.org/wiki/index.php/CSS_Styles) using CSS and themes (http://amarok.kde.org/wiki/index.php/Themes) are already available for download.

The speed of amaroK was impressive in tests. Adding about 8000 songs took roughly 5 minutes, which is respectable considering it takes at least twice as long in iTunes.

AmaroK also has a decent set of scripts (http://amarok.kde.org/wiki/index.php/Scripts) on the wiki available for download. They range from diplaying what song you're currently playing in IRC to allowing you to change songs without leaving Firefox to downloading podcasts.

Without a doubt, the DCOP functionality present in amaroK will be a decision-maker for some of you. While new to DCOP myself, IBM has a decent tutorial here (http://www-106.ibm.com/developerworks/linux/library/l-dcop/?ca=dgr-kdeml01KDEDCOP) that gives a nice overview of its capabilities. Basically the DCOP functions for amaroK allow the user to write his/her own scripts to control various aspects of the music player (ie: skip song, randomize playlist, raise volume, etc. )

For those you wondering what amaroK means, its inuit for wolf.