Draconis Software Blog

There are many times during a project where I use the svn log command in order to see what has changed and to get a feel for the pace of development. It's also great when you're dealing with clients; you're only one command away from telling an inquisitive client exactly who did what task and when they did them. However, svn log is missing one important feature -- the ability to filter by a particular username. When I asked in #svn on freenode, they suggested I use the --xml option and parse the resulting output.

The following is what I came up with. It's a ruby script that uses the delightful Hpricot gem to parse the xml. It takes one argument, the subversion username that you wish to retrieve the logs for. I hope that it's useful for someone else! You can curl it from http://pastie.textmate.org/197763.txt if that makes it easier, too.

Quick note here, that's especially useful to people using BootCamp on their Macs and don't want their Windows-formatted partition appearing on their desktop. To hide it whenever the Finder starts (it will still be mounted, but not visible on the Finder), open the Terminal and run the following command:

/Developer/Tools/SetFile -a V /Volumes/Untitled

Replace the "Untitled" with whatever the volume name is listed as in /Volumes. Note also, that you will need to have Apple's Developer Tools installed in order for this to work. It's free, but a fairly large download. Hope you find this useful!

Comments (5)

The latest and greatest Linux kernel (2.6.22) has just been released. Of the numerous interesting new features, I'm especially excited about two things: a new way to measure approximately how much memory a process is using (via the process footprint measurement facility), and the ability to measure file timestamps using nanoseconds for greater precision.

In addition, there's a new wireless stack, a new Firewire stack (very cool), and a slew of new drivers and other changes. Check out details about this release here, then download the kernel. Enjoy!

BugZilla 3.0 stable was recently released, and upgrading an existing BugZilla installation is easy. Yesterday, I spent some time upgrading our 2.22.1 installation to the new 3.0 and have, so far, been impressed with the updates. Here's a quick overview of the upgrade process (it might seem a bit unintuitive at first).
(Read the article)

Comments (2)

There's a good overview of antispam practices at Howto Forge today, detailing the various methods either currently in use (black/gray/white lists, applications, etc), and proposed (DKIM, etc).

In a world where spam is bound to hold such an important position,
methods of preventing it should also be given an increasing importance.
Some of the easiest and most widely used prevention methods are host
control solutions, Antispam applications and user education.

I'm particularly excited about Domain Keys Identified Mail (DKIM), which I wrote about recently. Such a method would be very useful in tracking down spammers and controlling the flood of junk they put out, though, as this article points out, it's not without it's limitations. "The main disadvantage of DKIM is that email messages can be significantly modified in certain situations (e.g. when being forwarded by list severs), causing the signature to be invalidated and the message to be rejected. A solution to this issue would be combining DomainKeys with SPF, because SPF is immune to modifications of the email data."

Check the article out - it's a good overview of what's currently going on, and perhaps may inspire you to try a different approach to your current antispam efforts.

In IT, many devices have an administrator password that, when forgotten, require some hoop-jumping to reset. Holding down the power button while booting the router/switch/etc, using a secret "back-door" password, or something similar is usually the norm. Not so with a Sony tape library, as this post at Everything Sysadmin shows. Talking to Sony tech support meant that, in order to reset the password on the tape library, it would cost $899 (escalating to Sony customer support dropped the price to $699):

The manual says that one can't reset the password and I should call my dealer. I figured they just didn't want the information spread around, so I contacted Sony and they gave me the right people to speak with. A very helpful person names Lucia informed me that I could send in the device and for only $899 they would reset the password. That seemed unreasonable, but escalating it brought me no joy. John Marshall, Customer Service/Support Manager at Sony ... was very polite and friendly, but was not able to tell me the secrets to doing the process myself. I even offered to sign a non-disclosure if the process was secret. No luck. He offered to reduce the rate to $699 but that was unstatisfactory.

That's an expensive password reset. Do you have a crazy password reset story? Let's hear it!

Fetchmail is one of the core Linux applications that I use consistently -- pretty much every email I get is passed through it before getting filtered, forwarded or backed up. It fills an important place in the email chain between the Mail Transfer Agent (or MTA) such as sendmail or qmail, and the Mail Delivery Agent (MDA) such as procmail (there's also MUA and MSA -- the architecture of email seems to demand MxA style acronyms). Fetchmail's place in this chain is to retrieve emails from a mail server using protocols like POP3 and IMAP, and then deliver them to local or remote users with SMTP.

HowtoForge has a nice tutorial on getting setup with fetchmail. Fetchmail's robust configuration system allows for a variety of setups. This allows for a number of uses:

1. Consolidating Accounts - It's common nowadays for a person to have many email addresses, such as work, ISP, school, as well as plenty of free accounts. With fetchmail you can check all of these accounts and forward them to a single address.
2. Usage of text-based email clients - Since fetchmail can also deliver to a local account, it allows you to store all your email on a Linux machine and read it using a client like mutt, pine, elm and others. This means you can check your email from any computer just by SSHing to your machine.
3. Integration with mail filters - It's easy to have messages be filtered before local delivery or remote forwarding. The Linux filter I use is procmail although there are many others. For example, you may want to filter out emails from a mailing list into a separate boxes. It also allows you to benefit from a spam filter that integrates with the mail delivery agent.

My personal email setup is rather complicated but it fits my needs very well. First emails are retrieved from my various accounts using fetchmail, and delivered to my local account with over Qmail. Procmail then filters out any spam, forwards the remaining emails to a separate email account, and then does further filtering before delivering to local mailbox files. The reason for doing this is it allows my email to be stored and backed up on my Linux machine, and if from any computer to SSH in and read email with mutt. But when I'm on my own computer, I can check the secondary account with Thunderbird, which gives me the benefits of a graphical mail client. It's these kinds of personalized setups that fetchmail (along with the rest of the MxA family) allows.

I recently saw an article about the DomainKeys Identified Mail (DKIM) draft being accepted by the IETF as an official proposed standard (even though it happened back in February). I really hope the acceptance of this takes off, though the article seemed to show many large companies (who could probably benefit from it) non-committal.

DKIM is a simple means for verifying the origination of an email in an attempt to better track (and fight) spam and phishing messages. The method is simple: the sender encrypts the message body using it's private key and stores this in the message header (non DKIM receivers, then, can safely ignore it and still deliver the message). A DKIM-enabled receiver looks up the originating domain's record and extracts the public key. From Wikipedia: "The receiver can then decrypt the hash value in the header field and at the same time recalculate the hash value for the mail body that was received, from the point immediately following the "DomainKey-Signature:" header. If the two values match, this cryptographically proves that the mail did in fact originate at the purported domain, and has not been tampered with in transit."

(Read the article)

I was working on a project recently that had a number of minor changes between revisions (a client of ours had made minor changes to a project we produced, keeping it under their own version control system), and I needed to sync these changes with a local copy. Since all of these changes were minor, and there were pieces in both versions I wanted to preserve, I would need to do diffs/merges by hand across each of the files (there were about two dozen). Well, diff/edit/close/repeat doesn't sound like much fun, so I thought a more streamlined approach was necessary.

My favorite command-line editor is vim - no, I don't mean to start a war here - and I knew I'd be using it quite a bit in merging these changes. In coming up with a streamlined approach, I found a vim plugin that does recursive diffs, splitting the screen up to show differences between each of the files, and allowing for streamlined sync's in the process. The plugin is called DirDiff, and is written by William Lee, and it proved very useful.

To install, just download the plugin, and place it in your ~/.vim/plugin directory (create it, if you don't already have one). Once installed, open vim and type irDiff [directory1] [directory2]. It found and diff'd each of the files in the directories correctly. It also has a nice feature of sync'ing files, one from the other, based on what you choose. I would have liked more advanced merge capabilities, as I couldn't take chunks from one file and have them merge into the other, but in most cases, the plugin proved very useful.

Recently we had to deal with some really big log files. One of our clients had an Apache access log several gigs large, and needed to logically separate entries for a new analytics package. The easiest way, of course, is to write a simple Perl (or any other language, such as Ruby) script, iterate through the file line-by-line, and parse each line. The problem here was speed and system resources: opening the file took several minutes on a very fast, SCSI RAID box, and used a huge amount of RAM. We realized there had to be a better way.

(Read the article)