Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

If you’re in the initial phases of setting up a new software project, one of the first things you should be thinking about is a project collaboration site. A good project site enables you to do at least two things:

  • Collect design documents and documentation in one place
  • Track and assign tasks/bugs/issues to developers

If used correctly, the project site can become a focal point for everyone working on a particular project. Ideas, research and design documents can all be collected in one place and collaborated over. At the same time the site is a management tool enabling assignment and tracking of tasks to a team of workers. This is surprisingly important even for small teams: if your project is a two man thing, there is still great benefit to knowing what the other person is working on and being able to see his or her progress.

A simple solution for your project site is to pick different kinds of software for different tasks. For example, you may choose to use Eventum for bug and issue tracking, with a separate MediaWiki installation set up for the documentation and design collaboration. But wouldn’t it be better to combine all of this functionality into a single piece of software?

Trac is one such piece of software. It gives you issue tracking, complete with SVN integration and wiki functionality, built into a single application. An added bonus of having everything in a single application is that you can make linked references to tickets, milestones and wiki entries pretty much anywhere you want within the application.

A Trac changeset referencing a ticket.
This changeset references ticket #3.

You also get a timeline which concisely summarizes what’s happening within the project, be it wiki edits or source code commits. This can be a very popular feature for project developers – it gives everyone a chance to see what’s happening in the project, and also to get a feeling for the ‘aliveness’ of the project.

A Trac timeline showing commit messages and wiki edits.
Timeline showing both edits, source code commits and ticket updates.

Installing Trac

Here’s Playing With Wire’s accelerated setup guide for Trac.

  1. Install the basic trac package using your preferred method (ports, emerge, rpms etc).
  2. Create a new folder for the trac website on your server.

    cd /www/
    mkdir mytrac

  3. Use trac-admin to create the instance:

    cd /www/mytrac
    trac-admin `pwd` initenv

  4. Answer the questions asked by trac-admin.
  5. Once the questions have been answered, trac will give you some instructions similiar to what’s below:

    Project environment for ‘MyProject’ created.

    You may now configure the environment by editing the file:


    If you’d like to take this new project environment for a test drive, try running the Trac standalone web server `tracd`:

    tracd –port 8000 /www/mytrac

    Then point your browser to http://localhost:8000/mytrac. There you can also browse the documentation for your installed version of Trac, including information on further setup (such as deploying Trac to a real web server).

    The latest documentation can also always be found on the project website:

  6. If you use SQLite, give +rw permissions to www for the database:

    chown -R :www db
    chmod -R g+rwX db

  7. If you need to install new graphics, e.g. a new logo file you will want to copy it into the actual htdocs folder: /usr/local/share/trac/htdocs

Httpd Setup

How to configure your web server depends on both what server you’re running and what method you want to use for serving trac (cgi, fast cgi or mod python). If you’re going to run trac using CGI, you’ll basically want to link to the main trac cgi file, and also set up serving of the supporting html documents. Here’s a sample config file for how it may look like with using Apache and CGI:

Alias /trac/chrome/common /usr/local/share/trac/htdocs
<Directory “/usr/local/share/trac/htdocs”>
Order allow,deny
Allow from all

ScriptAlias /trac /usr/local/share/trac/cgi-bin/trac.cgi
<Location “/trac”>
SetEnv TRAC_ENV “/www/mytrac”

AuthType Basic
AuthName “WireLoad Protected Area”
AuthUserFile /www/mytrac/.htpasswd
Require valid-user
<Directory /usr/local/share/trac/cgi-bin>
Options -Indexes +ExecCGI
AllowOverride None
Allow from all

AuthType Basic
AuthName “WireLoad Protected Area”
AuthUserFile /www/mytrac/.htpasswd
Require valid-user

This is fairly straight forward. The most imporant part is,

ScriptAlias /trac /usr/local/share/trac/cgi-bin/trac.cgi

which sets up trac as a cgi script accessible by going to the /trac address of the webhost.

For performance reasons, we don’t want the CGI script to serve every trac file. The following alias will override the /trac URL for the theme related files:

Alias /trac/chrome/common /usr/local/share/trac/htdocs

This has to go before the ScriptAlias line.

User Accounts

Trac’s login scheme is based on basic http authentication, which is why we added a the AuthType sections in the config file above. In fact, to log in to trac you simply authenticate with the web server using a user name and password from the .htaccess file.

Every user you define in the .htaccess file (using htpasswd) will be able to log in with some basic permissions. To configure the permissions more precisely, use the trac-admin command. For instance, to make the user with login ‘aljungberg’ an admin:

cd /www/mytrac
trac-admin `pwd` permission add aljungberg admin
trac-admin `pwd` permission add admin TRAC_ADMIN

This assigns the user ‘aljungberg’ to an admin group and gives the admin group the TRAC_ADMIN permission set.

Notice that everyone who logs in gets the ‘authenticated’ group permissions which are by default pretty useful. You can find what they are by running this command:

trac-admin `pwd` permission list authenticated

It’ll say something like:

User Action
authenticated BROWSER_VIEW
authenticated CHANGESET_VIEW
authenticated FILE_VIEW
authenticated LOG_VIEW
authenticated MILESTONE_VIEW
authenticated REPORT_SQL_VIEW
authenticated REPORT_VIEW
authenticated ROADMAP_VIEW
authenticated SEARCH_VIEW
authenticated TICKET_APPEND
authenticated TICKET_CHGPROP
authenticated TICKET_CREATE
authenticated TICKET_MODIFY
authenticated TICKET_VIEW
authenticated TIMELINE_VIEW
authenticated WIKI_CREATE
authenticated WIKI_MODIFY
authenticated WIKI_VIEW

Available actions:

To find out which permissions are available, check out the TracPermissions documentation page.

Setting up the SVN hook

To allow SVN commits to close tickets using cool syntax like ‘Fixes #1′ in commit messages, an SVN hook has to be installed. Hook scripts in SVN are described in the SVN documentation.

Enter a post-commit script in the hooks/ folder of your SVN repository:

LOG=`/usr/local/bin/svnlook log -r $REV $REPOS`
AUTHOR=`/usr/local/bin/svnlook author -r $REV $REPOS`


/usr/local/bin/python /www/mytrac/trac-post-commit-hook \
-p “$TRAC_ENV” \
-r “$REV” \
-u “$AUTHOR” \
-m “$LOG” \
-s “$TRAC_URL”

You may have to download the actual script from the repository. Make sure you get the right version. I initially accidentally got the latest version since I grabbed it from the SVN, and it wasn’t compatible with trac 0.10.3 which I had installed.

Finally make sure the script can be run,

chmod a+rx post-commit
chmod a+x /www/mytrac/trac-post-commit-hook

The users who run the script must also be able to read and write to the trac database. You can make sure this works by test submitting some change set for analysis:

su -m wlaljungberg post-commit /home/mysvn/myproject/ 4

If the database isn’t accessible you’ll get an error message similar to this one:

trac.core.TracError: The user root requires read _and_ write permission to the database file /www/mytrac/db/trac.db and the directory it is located in.

The hook is nice. Here’s a description of what it does, quoted from the actual script:

# It searches commit messages for text in the form of:
# command #1
# command #1, #2
# command #1 & #2
# command #1 and #2
# You can have more then one command in a message. The following commands
# are supported. There is more then one spelling for each command, to make
# this as user-friendly as possible.
# closes, fixes
# The specified issue numbers are closed with the contents of this
# commit message being added to it.
# references, refs, addresses, re
# The specified issue numbers are left in their current status, but
# the contents of this commit message are added to their notes.
# A fairly complicated example of what you can do is with a commit message
# of:
# Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
# This will close #10 and #12, and add a note to #12.

If you run into any trouble, take a look at the excellent Trac documentation. Good luck with your new project!

Author: Tags: ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

A while back we wrote an article called What’s Your Utilization, Kenneth. In that article we talked about a really cool web-app called Cacti. Today we will take this one step further by describing how to monitor remote servers using SSH tunnels.

In the scope of this article, we assume that you already have one Linux or Unix server configured with Cacti running. Moreover, we also assume that you have another remote server that you want to monitor (why else would you read this article?).

First we start by setting up the remote server. The first thing we need to do is to set up Net-SNMP. If you’re running FreeBSD, chances are that you already have this installed. If so, all you need to do is to change your community string and set up the daemon to bind on port 161/tcp instead of 161/udp. To do this, change/add the following lines in your snmpd.conf (/usr/local/share/snmp/snmpd.conf in FreeBSD):

com2sec local localhost public
agentaddress tcp:161

Once this is done, go on and restart the daemon.

To test that the SNMP daemon is working properly, try to run the following command:

# snmpwalk -v 1 -c public tcp:localhost:161

If your screen gets flooded with information, it worked. If not, please look over your log-files to find out what went wrong.

Next we need to create a secure user which we will be able to use to login from the Cacti-machine onto the remote machine. To maximize security, we suggest that that user has ‘nologin’ as shell and uses public key authentication instead of password. However, we will not cover how to create this user in this guide. Ask Google for help if you need it.

Repeat this for all hosts you want to remotely monitor.

That’s it for the remote server, now let’s move on to the Cacti host.

First we want to create a script that sets up the tunnel to the remote server. We suggest that you create a new user that will be running these tunnels (i.e. snmp). In order to make it easier to manage the tunnel (or tunnels if you have several hosts), we will create a bash-script that initializes the tunnel(s). In the home directory of the the user you created, create a file called with the following contents:

rm /home/snmp/tunnel.log

ssh -N -L 16000: >> /home/snmp/tunnel.log &

ssh -N -L 16001: >> /home/snmp/tunnel.log &

Note that this initalize two tunnels, one to server 1 (on port 16000) and one to server 2 (on port 16001. Also, don’t forget to chmod the file so that you can execute it, by typing chmod +x

Next we want to start up the tunnels using the snmp-user we created earlier. To do this run:

#sudo -u snmp /home/snmp/

If everything went fine, you should now have two tunnels running; one on port 16000 and one on port 16001. Now let’s test the tunnels before we move on to Cacti.

# snmpwalk -v 1 -c public tcp:localhost:16000
# snmpwalk -v 1 -c public tcp:localhost:16001

This should hopefully give you the the same output as you previously received when executing snmpwalk locally on the remote hosts. If this went well, all you need to do now is to add the hosts to Cacti.

First you need to log into Cacti with an administrative account. Then got to “Create Device.” In the Create Device field, as shown in the screenshot bellow.
Create Device

Hostname: tcp:
Host Template: ucd/net SNMP Host
SNMP Community: public
SNMP Version: Version 1
SNMP Port: 16000

After you’ve filled out the proper data, hit ‘Create.’ At the next page, just select the data you want to graph, and then hit ‘Next.’

That should be all you need to graph remote hosts. Now you may want to go ahead and add the host to a tree so that you can display it in the ‘Graph’ tab.

Author: Tags: ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.
Comments Off
Category: Uncategorized

Yesterday we migrated Playing With Wire from our old FreeBSD Jail to a brand new VMware Virtual Server. The new server has a much faster CPU and much more RAM, which we hope will decrease the load-time.

The migration itself went smooth without any downtime for PWW. If you discover something that appears to be missing or malfunctioning, please notify us at

Author: Tags: ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.
Comments Off
Category: Other

We had a couple of hours of downtime this morning as a new diesel generator was installed at Playing With Wire’s hosting location. Sorry about that.

Author: Tags:
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

SwtCallback 0.1 was released only a little more than a week ago, but that’s not stopping us from releasing 0.2 today! In line with the original philosophy, SwtCallback has been extended to again reduce clutter and deep nesting in your Java code. This time SwtCallback attacks the Runnable interface.

As I wrote in my release post about SwtCallback, SwtCallback is a java library for SWT applications which adds an alternative way to handle events: callbacks. Instead of clunky listener interfaces or messy anonymous classes, SwtCallback enables one line solutions that make it easy to keep your event handling code in a single flat class – this while still being more readable and (surprisingly) improving encapsulation in some cases.

This latest release extends this functionality from just listeners to anything that takes a runnable. Prime examples in SWT are display.syncExec(), display.asyncExec() and timers.

For example, maybe you wish to refresh some UI components to reflect a change in data. But you’re not on the SWT thread so you have to use syncExec. Normally, you’d do something like,

display.syncExec(new Runnable() {
  public void run() {

With a Callback you can turn this into one highly readable line:

display.syncExec(new Callback(this, "doUpdateSwtLabels"));

The most useful application may be for timers. In SWT, a timer needs to be reestablished at the end of timer execution if you wish it to recur. You may end up with unwieldy code such as,

void initWidgets() {
  /* ... */

  // Prime the timer.
  display.timerExec(INITIAL_DELAY, new Runnable() {
    public void run() {

void refresh() {
  /* ... update stuff ... */
  // Set the timer again.
  display.timerExec(TIMER_DELAY, new Runnable() {
    public void run() {

With a Callback you can now do this:

void initWidgets() {
  /* ... */

  // Prime the timer.
    new Callback(this, "refresh")); 

void refresh() {
  /* ... update stuff ... */
  // Set the timer again.
    new Callback(this, "refresh")); 

This is much easier to read and follow, at least in my personal opinion. If you agree, go ahead and grab the download below – SwtCallback is released under the BSD license so you should be able to integrate it with whatever you’re working on.

Download the source and binary here:

Download SwtCallBack. More information is available here.

There’s some extra javadoc in this release to make it easier to get started. Still, there isn’t much in the way of documentation – we’ll go back and write some if there’s demand for it.

Author: Tags: , ,

© 2006-2009 WireLoad, LLC.
Logo photo by William Picard. Theme based on BlueMod © 2005 - 2009, based on blueblog_DE by Oliver Wunder.