Linux

Redmine is a web-based project-management / bug-tracking tool, much like Trac, but so, so much better. Unfortunately, like so many web-based projects, there doesn't appear to have been much thought given to installing it on live, production systems - the general idea seems to be to unpack it in a random location on your server's filesystem and run it from there. Most sites I know would baulk at the idea of this, so I've created Debian and Ubuntu packages for it.

They're a little kludgy, at this stage - it seems to me that Ruby-on-Rails goes out of its way to be difficult to Debianise - but they work, nonetheless, and make installation fairly straightforward (although there are still manual steps involved - be sure to read the README.Debian). The packages depend on Mongrel, a small Ruby webserver; I tried getting Redmine to run under Apache, but running it with CGI was far too slow, and making it work with fastcgi appeared to be an exercise in futility.

It seems to be all the rage, lately, to eschew root shells and run all administative commands with sudo. Sudo is a great tool for allowing otherwise unprivileged users to perform certain tasks for themselves (and thus not having to annoy the sysadmin regularly) and it's also good for keeping logs of what tasks were performed.

However, what I'm seeing is a general trend towards educating people to administer servers by using sudo non-interactively. Eg:

$ sudo /etc/init.d/networking restart

instead of

$ sudo su -
# /etc/init.d/networking restart

Ubuntu documentation is notorious for this.

The first method is bad practice because it will automatically drop root privileges as soon as the command has completed. This means that if you've made a mistake, you can potentially lock yourself out of your own server.

The second method will return you to a root prompt after you've run the command, and - importantly - will allow you to check that everything still works. You should always be checking that changes you've made work, before you drop root.

Sounds unlikely? Hardly. Even with the best intentions, mistakes occur. I've seen this problem happen; a person using sudo accidentally nulled the /etc/passwd file and managed to lock himself out of the root account. If this had been able to be done using sudo su - instead, then he would have been able to test that he could still access root, from another window, before logging out of the root account in his original window. Unfortunately, site policies prevented this (although it could be worked around by copying /bin/bash to /tmp and then running sudo /tmp/bash).

And it's not limited to just nulling the password file. There's plenty of things that you can screw up that will lock you out of your server if you don't have a chance to check them first - /etc/shadow, anything under /etc/pam.d, /etc/sudoers, /lib/libpam-ldap.conf to name just a few. In Ubuntu's case, if you make a mess of the sudoers file, you might not even have a root password to fall back on, due to their insane insistence on not creating one at installation time.

It's nice to know that just occasionally, I'm ahead of the curve. Canonical have announced that they are planning to port Ubuntu to ARMv7. I'm not sure what differences there are between ARMv7 and previous versions, but I had ported Ubuntu Dapper to ARM over a year ago (actually, two years ago, but I didn't release it until August 2007).

I've taken down the binaries since then, as Nokia started a more professional porting effort than I could do on my own, but if anyone wants them, then just let me know.

gxine is my Linux media player of choice, partly because it's nice and light, but mostly because it just works, unlike certain other players which will remain nameless. It has a nice feature that allows only one instance of it to be invoked on any one desktop, so if you play a number of files/streams from external applications, you don't end up with multiple copies of gxine running.

Unfortunately, for the last few months, this feature has been broken in Debian (and Ubuntu too, so it seems ... and now that I look at it, the problem comes from upstream). A bit of a look into the code shows that the reason for this is that at some point, gxine moved its configuration files from $HOME/.gxine/ to $HOME/.config/gxine/ - a bizarre location which just reeks of GNOME or some other overly-pedantic committee - but the server code has been left in the old location, and hence the socket for communication can't be created.

The following (trivial) patch fixes it:

diff -urN gxine-0.5.903/src/server.c gxine-0.5.903.fixed/src/server.c
--- gxine-0.5.903/src/server.c  2008-08-08 20:29:48.000000000 +1000
+++ gxine-0.5.903.fixed/src/server.c    2008-02-12 04:18:45.000000000 +1100
@@ -40,7 +40,7 @@
 #define LOG
 */
 
-#define SOCKET_FILENAME "%s/.gxine/socket"
+#define SOCKET_FILENAME "%s/.config/gxine/socket"
 #define BUF_SIZE        1024
 
 static int       gxsocket;

Melbourne's tram operator, Yarra Trams, provides a web and sms system called TramTracker, that can tell you the time of the next tram that will arrive at any given stop, using a combination of real-time information and scheduled timetables. It uses the same system that drives the passenger information displays that can be seen around inner-city tram stops.

The web-service is pretty nasty, however. It doesn't render very well for me using Galeon, and worse, it doesn't keep any state information, so you have to keep retyping the tram-stop code every time you want to look up the information on your tram. And having to launch a web-browser to just look up the time of the next tram is annoying; it would be nicer to have either a command line interface, or perhaps even a small application running in a docked window.

It also assumes that you only wish to catch a tram from one stop; if, like me, you're within walking distance of two or more different tram lines that can take you to a particular destination, then you have to do multiple lookups, which is a waste of time.

So, with this in mind, I pulled out Wireshark and had a look at the HTTP traffic that was being passed when making a request to the service. The following was the most interesting part:

tkScriptManager=upnMain|btnPrediction&
tkScriptManager_HiddenField=%3B%3B
AjaxControlToolkit%2C%20Version%3D1.0.10618.0
%2C%20Culture%3Dneutral%2C%20PublicKeyToken% [blah blah blah...]
&__EVENTTARGET=&__EVENTARGUMENT=&__LASTFOCUS=
&__VIEWSTATE= [blah blah blah...]
txtTrackerID=1919&ddlRouteNo=Any&btnPrediction=

The number 1919 was the tramstop code that I'd entered. So I quickly threw together a small web form, with hidden variables txtTrackerID, ddlRouteNo and btnPrediction, which sent a request to the tramtracker interface, but unfortunately this wasn't enough and it kept returning to the start page.

After a bit of trial and error, I found that it also needed to be passed these variables: tkScriptManager, __EVENTTARGET, __EVENTARGUMENT, __LASTFOCUS and __VIEWSTATE. Fortunately it didn't need any of the long-winded variables with public key tokens in them.

I was rather happy to find that the output from the service was XHTML, however this feeling soon dissipated when I discovered that whoever wrote this clearly didn't have a clue that XML would only work if well-formed and that they hadn't closed off any of their br or img tags. Sigh, so many useless "web programmers" out there, so few jail sentences. This ruled out using XML::Simple to parse it, and I had to settle for kludging it with HTML::TableExtract.

The upshot of all this is the NextTram perl script, which will return the times of the next trams arriving at multiple tram stops, sorted by time:

$ ./nexttram 1419 1259 1216
1:Sth Melb Beach:0
19:Flinders St City:6
8:Toorak:9
55:Domain Interchange:10
1:Sth Melb Beach:13
19:Flinders St City:18
55:Domain Interchange:26
19:Flinders St City:31
55:Domain Interchange:39

While I realise that it has a limited potential audience (Linux/Unix users in inner Melbourne suburbs who actually care about what times trams run, ie, probably just me), I've released it under the GPL in the hope that it might go onto bigger and better things. Of course, it will probably just break next time Yarra Trams upgrades their website...

I quite like Docbook. The syntax is simple enough to pick up quickly, which means I can churn out documents without much effort, and more importantly, without having to fire up a bloated office suite. Furthermore, the documents that it produces look great, which is far more than I can say for anything I've put together with a wysiwyg word processor - I will freely admit that I have no artistic skills, whatsoever.

The biggest problem with Docbook, however, is the tools needed to convert it from xml to other formats (eg, pdf, html, etc) - or rather - the documentation of the tools, ironically enough. Most of the information out there seems to have been written to be so platform independent that it's next to useless for any real-world situation.

So, in the interests of hopefully saving someone the hours that I've spent trying to get this working for my specific case, here's a quick guide to writing and publishing a Docbook 5.0 document, on Debian sid.

Firstly, get the Debian package source to xmlto and apply the patch attached to Debian bug 416622; this gives xmlto support for dblatex, as it currently expects to use passivetex and it has been removed from Debian. Hopefully the patch will be applied upstream and this step won't be needed in the future.

Install the following Debian packages: docbook, docbook-xml, docbook-dsssl, docbook-xsl, dblatex, xsltproc. Build and install the patched version of xmlto, and install any dependencies it requests.

Now, a simple docbook document. Write this to index.xml:

<?xml version="1.0" standalone="no"?>

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V5.0//EN"
"http://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd">

<book xmlns="http://docbook.org/ns/docbook" version="5.0">


<info>
<title>My book</title>

<author>
<personname>
<firstname>Paul</firstname>
<surname>Dwerryhouse</surname>
</personname>
</author>
</info>

<chapter>
<title>Introduction</title>

<para>This is the first paragraph.</para>
</chapter>

<chapter>
<title>Stuff</title>

<section>
<title>Information</title>
<para>This is the first section.</para>
</section>
</chapter>

<chapter>
<title>Conclusion</title>

<para>This is the last paragraph.</para>
</chapter>

</book>

Note the DOCTYPE line. I can't tell if Docbook 5.0 has been officially released or not. Wikipedia suggests that it is, but the 5.0 DTD is not available on the OASIS website, only a beta.

You can now convert this to html with:

xmlto html index.xml

...or pdf with:

xmlto --with-dblatex pdf index.xml

If you're writing a huge document, and want to break it down into multiple files, then you can use XInclude:

<?xml version="1.0" standalone="no"?>

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V5.0//EN"
"http://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd">

<book xmlns="http://docbook.org/ns/docbook" version="5.0">

<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="info.xml" />
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="ch01.xml" />
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="ch02.xml" />
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="ch03.xml" />

</book>

The above example will then read in four files, info.xml, ch01.xml, ch02.xml and ch03.xml, which contain the information section and the three chapters from the first example.

Adding insult to injury:

It's bad enough that due to "heightened change procedures", I am required to submit a change request - with 14 days lead time - to compress a bunch of log files, on an 85% full filesystem. But for that change to then be rejected?

Fine, let it break. It'll cost more to fix it, then. At least I now know why my phone bill is so expensive.

A quick (and fairly obvious, now I think about it) tip for anyone who doesn't have time or inclination to manually insert dates and version numbers into changelogs: Debian's dch command (part of the devscripts package) can be used for more than just Debian package changelogs...

First, create a changelog file and edit it:

export EMAIL=your@email.address.com.zz
dch --create -c /path/to/CHANGELOG

Then, when you have a new release, either increment the version:

dch -i -c /path/to/CHANGELOG

...or give it a new version number:

dch -v 1.0.5 -c /path/to/CHANGELOG