Tuesday, May 29, 2007

Anti Virus Woes

My wife's laptop came bundled with Norton Internet Security 2006 and its update subscription expired recently. My options at this point seemed clear enough:
  1. do nothing
  2. purchase a new subscription
  3. uninstall
  4. uninstall and replace with a different product
    1. free
    2. non-free
The logic is also quite simple:
  • an updated security tool is better than an obsolete one
  • any security tool is a resource hog - but some are less hungry than Norton's
  • some security tools are better than Norton's
  • most non-free security tools are better than the free security tools
  • it's a laptop, and it's also my wife's laptop, and sh*t does happen

The performance claims above are based on independent benchmarks such as those conducted by AV-Comparatives.

I finally chose eset's NOD32 Anti-Virus over Kaspersky Anti Virus.

I uninstalled the Norton suite and then installed NOD32 trial version together with the ZoneAlarm Free firewall (it's becoming increasingly difficult to track down this free utility on the ZoneAlarm website - but you can get it direct from download.com).

I was quite happy with this setup - the laptop wasn't as slow as with the Norton tools, and it seemed to work without a hitch. It was only after the 30 day trial period ended, that I realized that I couldn't purchase a license online from eset's website. In that respect Norton is much easier - the registration process is simple, painless, and actually works (it makes sense - they do want my money).

I had to purchase a real boxed CD from a local dealer, uninstall the trial version and then install from the CD. What a drag.

I guess I'll have to go through this next year too.

Tuesday, May 15, 2007

Memory Upgrade

I've recently increased my laptop's memory from 256 MB to 512 MB. I've been meaning to do this for quite a while now, but I was worried about compatibility, and took my time checking all the options. Plus, cost was an important issue.

HP/Compaq dictates that only specific memory modules (e.g. 256MB module P/N 285523-001) may be installed in my laptop (costs around $200 and requires return of a defective part).

I went to the Kingston and Crucial (Micron) websites and selected the proper laptop model and got a list of memory modules that are guaranteed to be compatible with my laptop. These modules seem similar to generic modules of the same specification (DDR SODIMM, PC2100, CL2.5, 266MHz) but much more expensive (compare for example Kingston's KTC-P2800/256 at $42 with their own KVR266X64SC25/256 at $27).

I finally opted for a used generic memory module (at 15$). I got it from a friend of one of the sys-admins at work, with a promise that if it didn't work I could give it back to him. So how does one make sure that a memory module is functional? - well, it's quite easy:
  1. install memtest86+ like this:
    apt-get install memtest86+
    (this actually installs a new "kernel" that's dedicated to memory testing)
  2. shutdown the PC
  3. install the memory module (and yup - firmly push that sucker into its slot)
  4. turn on the PC - enter BIOS
  5. make sure the memory module is detected correctly (note that some memory may be used by the graphics accelerator, so that the reported memory size may be a bit smaller than expected)
  6. exit BIOS, and select memtest86+ from the GRUB menu
  7. memtest86+ starts testing memory automatically
  8. wait for it to complete at least one full test with no errors (takes about 40 minutes on my laptop with 512 MB)
  9. exit and commence with normal boot
Guess what? not keeping in trend with my previous posts here, it actually worked like a charm!

Thursday, May 3, 2007

Upgrading from "etch" to "lenny": Upgrading Bacula

As I said previously, the upgrade process to Debian "lenny" was painless enough, except for some problems with Bacula. I read the Bacula 2.0 release notes before upgrading, and I suspected problems in three areas:
  1. Storage device configuration: I use an external hard disk, connected via USB - and version 2.0 includes some improvements regarding such devices.
  2. Database: the database format has changed (I use the sqlite3 package), and it's necessary to convert the database to the new format, using a migration script.
  3. Scripts: I've configured several scripts to be run by the Bacula Director Daemon and the Bacula File Daemon, that perform some chores before and after the backup process. The scripting facility has been significantly overhauled in Bacula 2.0. The changes include modifications to the configuration file syntax, but the previous syntax is still available (e.g. the RunBeforeJob directive is implemented as a shortcut for a predefined RunScript block).
I half hoped that everything would just work, but I did not kid myself.
And sure enough - sh*t happened:
  1. I had no problem with the storage device - it's mounting is handled by an external script.
  2. The database conversion script was run automatically during the upgrade process, and did something really bad to my database - it contained no data after the upgrade!
    I intended to clear it anyway, because I wanted to split the backup pool in two - one pool for full backups and one pool for incremental/differential backups. But if this hadn't been my intent, I would've been left with a real problem.
    I did not investigate this any further. YMMV.
  3. The improved scripting facility caused an interesting problem:
    Background: the windows backup job inherited its properties from a default job common to all backup jobs. One of these is a ClientRunBeforeJob directive, that cannot be used on a windows machine, so that the windows backup job overrides this with its own ClientRunBeforeJob directive.
    Problem: the new RunScript facility allows several scripts to be specified, each with its own set of properties, so that the ClientRunBeforeJob directive in the windows backup job specification did not override the default job, but rather added another one. It so happens that this script was run first (on the windows machine) and then the File Daemon tried to run the default job's client script - this caused an error and the backup process died.
    Solution: I split the default job - one default job for Linux and one for Windows.
I kept the old backup for a week or so before I decided that the new setup works. It's not as if I had any option (I had no intention of going back to version 1.38), but it felt somehow more appropriate to wait.