Ubuntu Installed on New Server

When we last left our hero, I was struggling to get Ubuntu 10.04 (Lucid Lynx) up and running on a new server box with software RAID 1. Since that time, I have scoured the Ubuntu forums and searched the bug report databases, and found that I was not alone in my frustration. While misery does love company, this did nothing to help me resolve the situation at hand.

In the meantime, the flaky VMware server box continued to act flaky. I had had enough, and decided to try installing the previous release of Ubuntu, 9.10 (Karmic Koala). Unlike my previous attempts with 10.04, 9.10 installed perfectly the first time and I was in business! To quote John McClane in Die Hard, "Yippee-ki-yay, motherfucker."

The next step I took in my journey to server nirvana was to read up on Ubuntu's Uncomplicated Firewall, ufw for short. As the name implies, it is trivial to set up and use if you have a modicum of networking knowledge (quick test: on which port does an HTTP server usually listen?). Using ufw, I locked down the server nice and tight, allowing connections from our local network and my home IP address (for remote administration).

Next came the virtualization software installation. I have become convinced that VMware Server is not the virtualization software for me. The web based administration software was nice, when it worked. However, I found that when I most needed it to work, it oftentimes did not. In that, it is remarkably like an automobile not starting up in a bad horror movie.

I've worked with VirtualBox as a desktop virtualization solution, and knew that it could also operate in a "headless" (think no GUI) mode. So, I took the plunge and install VirtualBox 3.1 on the new server. If you want to look into installing VirtualBox for a similar purpose, I can't recommend this site enough - it helped me out enormously and walked me through the process in an almost pain-free manner.

Thankfully, VirtualBox can use VMware server's virtual disk drive files (vmdk), so I moved our web server virtual machine over from the old VMware install to the new VirtualBox ... ummm... box. My heart stopped a bit when I first tried to start up the new virtual machine, as it would not boot. However, after checking the "Enable IO APIC support" in the virtual machine settings, I was off and running.

I am going to hold off on moving any other virtual machines from the old to the new until I am confident in the new system. Or the other one blows up - whichever comes first.

Trying Out Ubuntu 10.04 RC1 - Fail!

The main server at my place of employment which houses three virtual machines (two linux, one XP) has been acting very flaky over the last month or so. The server tends to crash and restart itself, with the virtual machines sometime coming back up, and other times not.

The reason why the virtual machines do not come back up sometimes is due to the presence of VMware's .lck directories, which do not always get cleaned up appropriately. So, I have to go in there and remove the offending files, and then start the virtual machines back up via the VMware web console.

I have tried just about everything I can think of to find the cause of the server reboots. Temperatures of the four CPU cores is good (checked via the sensors command), as are the hard drives (checked with hddtemp). I've tested the memory, and all looks good there. So, I am at my wit's end.

The server is running Ubuntu 8.04 LTS, and a new release of LTS is due out tomorrow. I thought that I'd try installing the release candidate on a new server box I put together recently, and see how it faired. Unfortunately, after making my way through 98% of the installation, the installer failed when trying to install the grub2 boot loader.

Gah. There is an option for the legacy grub boot loader, so I tried that. No joy. I am not trying to installed the server OS on exotic hardware here. It is a RAID 1 setup, but I was able to install the same setup in 8.04. I have heard that there is a bug in grub2 relating to multi-boot systems, but that doesn't apply to my setup.

Frak. Frakfrakfrakfrak!

Now Using Greylite

In this old post, I spilled the beans on my new and improved spam filtering triple play: dspam, qgreylist and RBL checking. Overall, the system has worked well over the last four months, though I have noticed the increasing volume of spam showing up in my spam folder.

I suspected that the very simple form of greylisting implemented in qgreylist was the culprit, and after a bit of investigation, I found out that this indeed was the case. So, I set out to see if there was another greylisting implementation which could be used in my qmail installation.

Using my google-fu, I quickly zeroed in on Greylite. After reading up on it, I found that it held several advantages over qgreylist:

1. Written in C instead of perl, so it should perform a bit snappier and be less of a burden on the mail server.
2. Instead of only considering the IP address of the sender as qgreylist does, greylite considers the complete triplet of {IP address, from, to} before validating an IP address.
3. All data is stored in a single sqlite3 database, whereas qgreylist stored the verified IP addresses as files in a single directory, which clutters the filesystem and increases access time in that directory as more IPs are validated.
4. Greylite appears to have some enhanced functionality called `tuning suspicion' which allows you to customize how it behaves in certain circumstances.

To install it on my debian box, I first had to install sqlite3 (and the associated development libraries). Then, I downloaded the source code and followed the simple directions that came with it.

Less than 5 mintues later, and the server was up and running with its new greylisting implementation up and working perfectly. Flawless victory!

By Request - My dspam Training Script

In a post I made about one year ago, I mentioned a script which I created which trains dspam to recognize missed spam email, and corrects it when it falsely identifies a good ( or "ham") email as spam. Someone has requested that I post that script, so here it is. Please note that my qmail installation uses the maildir format!

--- start file: train-spam.sh ---
#!/bin/sh

# train-spam.sh
#
# Description: Checks each user's /home/Maildir/.Spam.Missed
# directories to see if the user placed any "missed" spam
# messages which got through SpamAssassin to their INBOX.
# If there are messages in this directory, then the script
# invokes sa-learn to update the site-wide tokens to try
# and improve the defenses for next time...
#

# learn_spam - Function which takes a directory and a user as
# arguments, and then feeds that directory to our anti-spam
# applications for further SPAM training.
#
# Arguments:
# $1 - Directory name containing SPAM emails. Required
# $2 - User name. If it is not provided, $USER will be used.
#
# Example:
# learn_spam /home/alank/Maildir/.Spam.Missed/cur alank
#
function learn_spam {

# loop through all emails in given directory
for email in $(ls $1); do

# process SPAM email using DSPAM
/usr/local/bin/dspam --mode=teft --source=error --class=spam --feature=chained,noise --user $2 < $1/$email
echo -n "."

# delete SPAM email
rm $1/$email

done # end of email loop

} # end function learn_spam

# learn_ham - Function which takes a directory and a user as
# arguments, and then feeds that directory to our anti-spam
# applications for further HAM training.
#
# Arguments:
# $1 - Directory name containing HAM emails. Required
# $2 - User name. If it is not provided, $USER will be used.
#
# Example:
# learn_ham /home/alank/Maildir/.Spam.NotSpam/cur alank
#
function learn_ham {

# loop through all emails in given directory
for email in $(ls $1); do

# process HAM email using DSPAM
/usr/local/bin/dspam --mode=teft --source=error --class=innocent --feature=chained,noise --user $2 < $1/$email
echo -n "."

# delete HAM
rm $1/$email

done # end of email loop

} # end function learn_ham

#
# Script starts here!
#

# loop through all user home directories
for file in $(ls /home); do

# if there is a Spam/Missed maildir
if [ -d /home/$file/Maildir/.Spam.Missed/cur ]; then

# then process any missed SPAM
echo -n "missed spam for $file: "
learn_spam /home/$file/Maildir/.Spam.Missed/cur $file
learn_spam /home/$file/Maildir/.Spam.Missed/new $file
echo ""

fi # end if

# if there is a Spam/NotSpam dir
if [ -d /home/$file/Maildir/.Spam.NotSpam/cur ]; then

# then process any falsely identified spam, i.e. HAM
echo -n "false positives for $file: "
learn_ham /home/$file/Maildir/.Spam.NotSpam/cur $file
learn_ham /home/$file/Maildir/.Spam.NotSpam/new $file
echo ""

fi # end if

done # end for loop

echo "Done!"
--- end file: train-spam.sh ---

I place the above script in /root and create a cron job to run it every day in the early morning. You will need to edit some parts of the script if your missed spam and not spam directories are named differently. Good luck, and I hope it is helpful in your continuing battle against spam!

The War on Spam

It was earlier this year that I last detailed some steps taken in an attempt to thwart the growing junk email (a.k.a. SPAM) epidemic. dspam has continued to work like a champ, with an accuracy rate currently standing at 99.13%.

However, the volume of spam continued to increase, almost as inevitable as the rising tide. I didn't let it bother me too much, as I could simply delete the messages sent to my spam folder, although I had to admit that looking through all of those messages for false positives was getting a bit tiresome.

And then it happened... The event that moved me past the tipping point, and thrust me forcefully back tot he front lines of the war on spam. The event seemed innocent enough: I went to send an email, and our smtp server (qmail) did not respond. wtf?

I shut down qmail, restarted it, and it seemed to work for a while. However, after an hour or so, the same problem arose. wtf?

Looking at the process list, I noticed that there were 40 qmail-smtpd processes running. What were they trying to send? Time to get my hands dirty and learn a bit about qmail's queue. I read a bit on the queue, and installed a tool called qmqtool. By using this new tool, I discovered that I had over 6,000 messages awaiting deliver in my mail queue!

Why so many? Because for every spammer that sends an email to a bogus address, a mail server will craft a bounce message and attempt to send it back to the (usually faked) sender. Gah!

As a first step, I decrease the queue lifetime to 24 hours. After 24 hours, any message still left undelivered in the queue would now be deleted. Then, I cleaned out the queue and restarted qmail. It worked!

...for a while. Ok, so let's do some more furious reading on the subject of spam prevention in the qmail environment. First of all, I needed to increase the maximum number of qmail-smtpd processes which were allowed to run simultaneously by tcpserver. By adding a "-c 400" to the tcpserver command used to execute qmail-smtpd, I increased the maximum number of simultaneous connections from 40 to 400. That ought to be a good start.

Now, how else can I decrease the volume of spam? I had heard of greylisting before, and thought that it might be a good next step. Luckily, there is a simple greylist implementation for qmail called qgreylist. It installs fairly quickly, and does a fairly good job. However, it is written in perl and with all of the spam emails flowing in, it can cause a bit of a performance hit.

So, maybe there is something another check I could do before sending the incoming email to qgreylist? How about an RBL check! When another computer attempts to deliver an email to our mail server, the RBL (Real-time Blackhole List) check sees if the sender's IP address in a list of know spam servers. If it is, then the connection is dropped and the email never even is seen by the greylist app.

With the above changes made to our mail server, I am now receiving about 10% of the spam volume that I was before the changes were made. Furthermore, our remote queue sits at a fairly steady level of 400 messages.

Only time will tell for how long this solutions will suffice! Wish me good luck and my email godspeed!

Upgrading to Ubuntu 7.10 - Gutsy Gibbon

As mentioned in previous postings, I use Ubuntu as a desktop OS both at home and at work. At home, I have had Dapper Drake installed on an older Dell Inspiron laptop with a D-Link DWL-650+ wireless PCMCI networking card, which functions perfectly. The kids will even hop on it to browse the web with Firefox or write a paper using OpenOffice.

At work, I have a dual Opteron Dapper Drake box on which I do any Linux and/or C based development. It has been rock solid for well over a year. I also recently installed the 64-bit version of Feisty Fawn (7.04) on a spare AMD64-3200+ system to test 64-bit development using Free Pascal.

When I heard Ubuntu 7.10 was released, I looked through the notes and thought that it might well be time to upgrade my Dapper boxes, as Firefox was getting rather long in the tooth (the Dapper version being stuck on the 1.5 branch), and I also wanted to investigate mono development (more on this in another post!). Since mono development is still rapidly evolving, I wanted to look at a recent distribution.

The first box I went to upgrade was the AMD64 system. I had little to lose on the system, and so elected to do a clean install, nuking the previous distribution. Everything installed smoothly, so I played around with the distribution for a while to see what was new.

The installer had detected the motherboard's integrated Nvidia video controller, and offered to install the restricted driver for me to increase performance. I accepted, then turned on some of the flashy desktop effects provided by compiz, and was pretty impressed with some of the flash and sizzle. To get finer tuned control over what compiz does and does not do, I installed the compizconfig-settings-manager using synaptic.

Next check - Firefox and the network. The integrated NIC was detected and automatically setup - no work necessary on my part (since I recently switched our work network to providing DHCP addressing). Firefox seemed to work well, and when I visited a page that used Flash, it offered to install the 32-bit flash plugin with all of the necessary wrappers and libraries so it could be used in my 64-bit Firefox. Until Adobe can provide a 64-bit flash plugin, this is the next best thing and it worked flawlessly.

Ok - the box looks and works well, so it was time to test the next system in my parade of installs. Hmm... Let's try the laptop at home. I burned a live cd of Gutsy and took it home. I booted up the laptop with the CD, and wireless networking was dead - frak! This has been a problem with this laptop for the last three ubuntu releases. I decided to come back to the laptop at a later time.

Next stop - the dual opteron development workstation. What to do, what to do? I didn't want to do a clean install this time, being a somewhat lazy sob. I decided to back up my important files to another computer and do an inplace upgrade from Dapper to Edgy, then from Edgy to Fesity, and finally from Feisty to Gutsy. This seemed to me to be somewhat risky, but I wanted to see how Ubuntu fared when doing inplace upgrades. If it came through THREE upgrades, well that's a pretty damn strong endorsement.

So I first upgraded from Dapper to Edgy by following the instructions here. It took a while, I had to confirm a couple of file overwrites, and about 3 hours later it said it was done. Reboot the machine, and all looked well. Did it again for Edgy to Feisty, and one more time for Feisty to Gutsy.

Once the upgrade to Gutsy was done, I took a close look at the system. Compiz was not working, and I found tha I needed to install xserver-xgl for compiz support. Fonts were a bit tweaked, but I managed to get them workig with a couple of corrections to the FontPath section of the file /etc/X11/xorg.conf.

Overall, I was *very* impressed with the three distribution upgrade. This gave me the confidence to try it with the laptop at home, and so I did. To make a long story short, I am now writing this post from the Dell Inspiron upgraded to Gutsy, with wireless networking and flashy desktop effects turned on. It's not super speedy, but once things are loaded into memory, everything runs swimmingly.

I just checked fonts in emacs, and they are fairly screwed at this point in time. I may have to check out my font paths on this system, and if I recall correctly, I had to change the default fonts emacs uses to get non-horrid looking fonts on the dual opteron system.

The Day from Hell

I know it is cliche, but Mondays can really be hell sometimes. On Sunday, I received an email from the mail/web server at work, notifying me that one of the hard drives in the RAID-1 array (mirrored) had failed. So, I readied myself for some server work on Monday.

I pulled out the faulty HD, and replaced it with a backup drive. I then start up the server, and watch the handy messages go by, until the system freezes at the partition check. Oh... no... Try a few more ideas, and still no go. Both hard drives died at the same time? Come on!

Time for the backup plan. I had prepared a Debian Etch server just for this event, and it was time to press it into service. I got it up and running, accepting email and serving web pages. Unfortunately, the server was not serving its role as a gateway to the regular desktop systems behind it. Frak! Something was (not) going on with the ip masquerading functionality. I installed the ipmasq package, but all packets were being dropped by the server, so no outgoing connections were possible. The server could access both subnets, but no joy for the desktops.

Damn, damn, damn! Now what? 6 hours later, and I am now seriously screwed sideways and upside down. I am sweating profusely, and am almost ready to give up. I call a local "Debian" consultant, but it turns out he's not real familiar with iptables/nat. What to do... what to do?

I finally get the idea to try the hard drive from the additional server in another box, as I kept coming back to the fact that having two hard drives fail simultaneously seemed a bit suspect. I powered up the box, and voila! She booted, and everything looked good! I moved the NIC cards over from the old box, placed the spare hard drive in her, and fired it up. After partitioning the new drive and marking said partitions for linux raid auto-detect, I was able to add the new disk partitions to the existing raid array, and everything seems good so far.

Needless to say, I learned a few lessons:

1. My backups of the mail from the mail server worked well. However, there was additional information that should have been backed up but wasn't. This has been remedied.
2. Even if you go to the trouble of making a backup server, you need to test it in exactly the same kind of conditions in which you need it to function. I tested out the services and such, but not the iptables/nat requirement (thinking it would be a breeze - ha!)
3. I need to find a way to move my OS from one set of hardware to another. I'd rather avoid the reinstall and subsequent system build up if at all possible, but this might be too much to ask. If you have any ideas, lemme know!
4. I *really* need to buy some new server hardware.
   

So, things are bck to normal now. I figure I lost at least a year of my life in those eight hours, and it wasn't until T+24 hours that I actually started feeling normal again. Maybe I should look into Google hosting our email...

Odd GCC Optimization Issue

I am working on a modification to some C code for a customer, and stumbled upon an odd problem with the GNU C Compiler (gcc version 4.0.3-1ubuntu5). The code computes payments and amortization schedules for requested loans, and returns the information in data structures.

I noted the problem when writing a payment stream generator (e.g. "x payments of $a", "y payments of $b", etc.). With optimizations turned off, the payment stream was being output correctly for the loan in questions (2 payments of $47.26 followed by 4 payments of $2530.39).

However, once I turned on optimization (-O2), the payment stream gave me a hiccup and reported: 1 payment of $47.26, 1 payment of $47.26, 4 payments of $2530.39.

Hmmm - odd. Printing out the first two payments to 15 decimal places revealed an extremely slight difference (47.259999999999998 vs. 47.260000000000005), even though the two values are computed using the same factors, rounded in the same manner, etc.

I wish I could reduce the code to something simple for demonstration purposes, but the code is extremely complex and has many dependencies on other units, so it would not be a trivial matter to say the least.
For now, I have replaced the -O2 optimization flag with the following: "-finline-functions -floop-optimize -falign-functions -falign-loops -funroll-loops". With those optimization options turned on, the results are as expected.

I just checked to see if the same issue occurred with an older version of gcc (version 3.3.5 Debian Sarge) and the same problem does appear. Odd.

Porting a Win32 Delphi Library to Linux

As I have mentioned in different posts, the primary product at my place of employment is developed for the Windows 32 bit platform, using Delphi. In the two previous posts, I looked into moving this code over to the .net platform, and came away fairly successful in the endeavor.

One of our existing partners asked us about providing our library on platforms other than Windows. This partner wanted the library to exist natively on many different Unix / Linux variants, and wanted to know would this be possible, etc.

A while ago, Borland offered Kylix, a product for both Windows and Linux. Unfortunately, that product is no longer offered, and I can only assume that the product was not as successful as Borland would have liked, given that it is no longer available. Furthermore, it was only functional for a given subset of the Linux platform, so I went looking for other ideas.

Next stop - Free Pascal. After looking over the site, I noticed that it seemed to offer quite a few platforms - 32 and 64 bit Intel processors, Windows, Linux, FreeBSD, Mac OSX, etc. However, how compatible is it with Delphi code?

There was only one way to find out, so I downloaded the .deb files (usable with my Ubuntu Linux box) and got hacking. After roughly one week of looking over the tools and available documentation, I have successfully compiled a shared library which contains a subset of the functionality provided in our native Windows product. I have compiled a C application which successfully links to this new shared library, which means that just about any language our there should be able to talk to it. Not too shabby!

Next, I need to port over the XML processing code to use the components provided in the Free Pascal component library, which may take a bit more time. However, I am very happy with the productivity and compatibility so far, and our partner was enthusiastic as well!

DSPAM Installed

At work, we have a Debian Linux box that serves as our mail and web server. Recently, I upgraded that box from Debian Woody to Sarge. After that upgrade was complete, I decided to try and improve upon the spam filtering implementation.

The mail server runs qmail as the SMTP server, and I have the mail delivered to local users via procmail. Using procmail allows me to do all kinds of neat filtering on the server side. As an example, I automatically place mailing list traffic into separate IMAP folders. Similarly, mail from customer domains is automatically placed in their own company specific IMAP folders, thereby organizing my incoming emails automatically.

One of the filters that I had incoming mail going through was SpamAssassin. When I first installed SpamAssassin 2+ years ago, it did a very good job of detecting and flagging spam. However, the spammers have gotten rather sophisticated over the last two years, and many of them now actually test their spam against SpamAssassin to try and thwart it. While SpamAssassin was still able to detect and flag an ample amount of spam, more and more seemed to slip through as the months went by.

I decided to try out DSPAM after hearing good reports on its performance from a friend, and reading about it on its website. It wasn't available in the Debian repository, so I downloaded the source tarball and then built and installed it.

DSPAM works best if you have a corpus of spam and non-spam (or ham) to train it. If you do not have a good selection (in the thousands), then I would recommend not using it until you do. Once you train DSPAM with emails that are good and bad, then you can put it to work effectively.

DSPAM is not a fire and forget type of spam fighting solution. It requires a certain amount of vigilance on the part of the user to correct falsely flagged spam or ham. I set up three folders in each user's IMAP folder hierarchy for this purpose:

1. Spam/ - This is the folder where DSPAM sends all emails it detects as spam.
2. Spam/Missed/ - This folder is where users place emails which DSPAM did not detect as spam, but should have.
3. Spam/NotSpam/ - This folder is where emails are placed which were detected as spam, but are not.

Every night, cron executes a bash script I wrote which crawls through the Missed/ and NotSpam/ directories, correcting DSPAM's mistakes.

So, how is it working? After about 3 weeks of use, my accuracy rate is up to over 95%, and that is with out as much initial training as I recommended. I expect that over the course of the next month or two that I will be able to get that accuracy up to the triple 9's range - 99.9%.

Over all, I am extremely happy with DSPAM's performance. It is a bit trickier to install and get going, but once it is humming along nicely, it purrs.

Yet Another Reason to Not Upgrade to Vista

I've pretty much avoided discussing Windows Vista on this blog as I really haven't found many interesting tidbits about this new OS. I am of the general opinion that Vista is an XP "point" upgrade - like XP.5, or something like that. It isn't adding features with which I am particularly impressed.

High on my list of annoyances are the many different flavors of Vista available (5, I think), and the lack of a clear message detailing what you get (or don't get) with each version. I can see many people looking at the various flavors and saying, "WTF?".

Much of Vista's marketing push seems to focus on the user interface enhancements made to the system. Of course, to make optimal use of these new enhancements, Microsoft recommends a computer with a pretty hefty set of requirements - a list which many non-gaming PCs will fail to meet. So, you could run Vista in a "degraded" mode where many of the UI changes are not present... and end up with a product similar to XP.

Microsoft has also made a fairly draconian change in the usage of the upgrade editions of the new OS. In the past, upgrade editions could either be upgraded over an older version of Windows, or you could do a fresh install on a blank hard drive. This came in handy, as it was common practice for some to reinstall Windows annually to clear out all the cruft that accumulated. Also, it is essential to do a clean install when a system has been infected with a rootkit and/or many viruses.

To reinstall a Vista upgrade edition OS, you will first need to install an older version of Windows, and then do the upgrade all over again. Either that, or you could bend over and fork out a good chunk of change for the "Full" Vista (insert flavor here) Edition.

If you have XP, then I'd recommend not upgrading to Vista. The extra hardware costs needed to receive the full benefits of Vista plus the hose job Microsoft is handing out for their "Upgrade Edition" are just too much to swallow. Stick with XP on those Windows boxes you need, and maybe look at trying out a Linux distribution like Ubuntu for others.

If you need to get Vista, I'd look at buying a new PC and getting it bundled with the system. For the full retail price, you might as well get a system that works well with it at the same time.

Upgrading from Debian Woody to Sarge

At work, I use Debian linux as the distribution of choice for our file and mail/web servers. In my experience, the stable branch of the the Debian distribution has been very, very stable. When it comes to file and mail servers, that is exactly what I am aiming at - stability!

Each Debain stable release has a code name based upon (so far) one of the characters in Pixar's Toy Story. The current release is Sarge, the previous release was Woody, and the upcoming release is Etch. Sarge has been out for quite a while, with security updates continuing for Woody up and until the first of the new year.

I upgraded our file server from Woody to Sarge sometime last year, and experienced no problems. I was a bit more concerned with our mail/web server, as it serves important public facing functions for my company.

With solid backups prepared and a bit of trepidation in my heart, I began updating the mail and web server. I followed the directions published in the release notes, and experienced only a few minor hiccups along the way.

After about 200MB of downloaded updates and a bit of intervention from me, the system was ready to go. Email worked fine, as did our web server. All in all, a relatively painless upgrade path!

The next release of Debian is due sometime in the near future. However, right now everything seems to be working just fine, so I'm betting that Debian Sarge stays on these servers for the next year or so.

Adobe Flash 9 Beta for Linux is Here

For those of us who use linux and have been suffering with Adobe Flash 7 for the last few years, today we finally receive some good news. Flash player 9 beta is available for download!

I have installed it on my Ubuntu dual Opteron box here at work, and immediately noticed that the audio seems to synch up with the video just fine. Woo-hoo! So, go grab and install it, and give it a whirl.

How to Salvage a Subversion Screw-Up

Yesterday, one of the developers at work attempted to add approximately 14,000 files to one of our subversion (aka svn) source control repositories. The svn server itself resides on a linux box, but the interface the developer used was TortoiseSVN, a Windows explorer based interface that is pretty slick.

Anyhow, the attempted addition of 14K files caused TortoiseSVN to choke. Futhermore, actually checking out the repository with all of these files added takes almost an eternity in developer time, and also causes TortoiseSVN to choke.

So, I knew what I had to do - remove the files added in the offending transaction. Now, how do I do that?

After a bit of googling about and reading through the administration chapters of the svn book, I realized that I would have to dump the repository (minus the offending transaction), and then rebuild a new one.

Looking over Trac (our project management app that integrates nicely with svn and provides bug/ticket tracking etc.), I found that revision 688 was the culprint. Thus, after a bit of trial and error, I finally zeroed in on the following comman (executed from the bash shell on the linux box) to dump the repository as desired:

svnadmin dump [repository path] --deltas --revision 1:687 | gzip > ~/dumpfile.gz

Next, I renamed the old repository directory to [repository path].old, and created a new repository to fill back up.

Finally, the step I was waiting for - loading the new repository up with the good transactions:

gunzip -c ~/dumpfile.gz | svnadmin load [repository path]

After a few minutes of churning away, svn finally notified me that revision 687 was committed, and I am now ready to go! Woo-hoo!

Accessing Password Protected Remote Calendars with Evolution

You can access a password protected remote calendar from evolution by specifying a url in the following format:

webcal://username:password@servername.com/path to calendar/calendar.ics

Unfortunately, as of evolution 2.4, the remote calendars are still read-only. :<

Cleaning Up Your Debian Box

If you use Debian GNU/Linux, you know that it has a solid reputation of stability and durability. I just recently upgrade a file/print server here at work from the "Woody" distribution to the newest stable release - "Sarge". The upgrade proceeded without a hitch, and it was all done by editing a single file and then issuing one command from the bash shell. It doesn't get much better than that for the ever-stressed out network administrator! Furthermore, Debian provides extremely timely security updates which are likewise installed in the same painless manner as the distribution.

For those who would prefer to be more on the cutting edge of Debian development, there are also "testing" and "still in development" distributions which provide more recent packages. These meta-distributions are actually the workplaces for the next stable release, but are constantly upgraded as packages are improved, fixed, etc. These testing distributions are also pretty damn stable, but there is more package-churn here than in the stable branch, where packages are updated only for security issues.

The only downside to Debian's stability is that over the long period of time in one of the testing distros, you can get some unused packages left behind. Today, I found a useful package in Debian called deborphan. As you might guess, deborphan scans the list of installed packages, searching for orphaned libraries that are no longer needed. Using the list it prints out, you can then remove these orphaned packages and free up some disk space.

If you don't have deborphan installed yet, install it:

apt-get update
apt-get install deborphan

Of course, you could use aptitude as well - whatever you prefer. Next step, run deborphan and see what packages it thinks you no longer need:

deborphan

Look through the list carefully, and make sure that nothing seems out of the ordinary. If you want to fully remove all of the listed packages, then try:

deborphan | xargs apt-get --purge remove -y

This command will purge all of the packages listed in the previous step from your system. I just did this a few minutes ago on my Debian sid workstation, and it freed up around 106 MB.