reiserfs and dd_rescue for data recovery

Last thursday the hard disk drive on a development machine died big time. First it started to behave erratically and dmesg showed that it has having trouble with some bad blocks. It did not survive a reboot: ReiserFS woud not mount it on boot, and reiserfsck running from an Accelerated Knoppix CD refused to bring it back to life. At first glance, the disk was beyond repair.
Of course, upon closer inspection, it turned out that the warranty expired exactly two months ago. Normally -after swearing my heart off- I would just replace the disk and make myself a nice paperweight or some other modern art piece -I’ve been looking forward to make one of those nice HDD clocks– but in the guts of that particular HDD were some uncomitted changes that I just wasn’t on the mood of rewriting. Besides, even though most of the data was expendable, the configuration hadn’t been backed up in quite a while (Yes, there is a pattern here).
So here’s the recipe I usually apply in these situations using Kurt Garloff’s dd_rescue. First get a brand-new HDD of approximately the same capacity and place both disks in a working Linux box (Depending on your necessities, booting from Knoppix might do). Let’s call the old, dying HDD /dev/hdg, and the spankin’ new disk will be /dev/hde. For the sake of simplicity, let’s assume that /dev/hdg was partitioned in /dev/hdg1 for swap and /dev/hdg2 for data.
First we’ll copy the entire data partition from /dev/hdg2 to /dev/hde2:

# dd_rescue /dev/hdg2 /dev/hde2

This will take a long, long time. dd_rescue starts with a reasonable block size, but whenever it encounters and error it retries a few times with a smaller block size before skipping the defective blocks and moving along. This is useful because it will copy all data in every readable block, instead of giving up at the first error like dd does. In my case, this took more than a day for a 248GB partition.
Once the data is in a new disk you can try to mount it directly, although it is a good idea to run reiserfsck first to make sure that the files you’ll copy are usable.

# reiserfsck /dev/hde2

Now here you might run into a small obstacle. Ideally I would buy the exact same model as the old drive for recovery purposes, because that guarantees that an exact bit-for-bit copy will work in most cases, partition maps and all. However in this case I bought a different brand, which resulted in a slightly smaller drive and a completely different geometry. When this happens, reiserfsck will complain about the different partition size, and suggests that you rebuild the superblock:

# reiserfsck --rebuild-sb /dev/hde2

Now you can do a normal reiserfsck.
When you’re done just mount the new partition and copy your data to a safe place:

# mount /dev/hde2 /mnt/tmp
# rsync -a --progress /mnt/tmp/etc /backup/dir/
# rsync -a --progress /mnt/tmp/home/arturo /another/backup/dir/

After this you can reformat the new drive for normal usage. Mine is being debbootstrapped as I write this.
This little recipe has saved quite some data and a few disks, including most of mcleod’s late Xbox hard disk. As usual your mileage may vary, but with a litle luck you just might get some of your files back.
Now about that crappy Maxtor HDD… I might just go for the wind chimes instead.
[tags]Linux, sysadmin, reiserfs, dd_rescue, data recovery[/tags]


Gammu -the GNU All Mobile Management Utilities formerly known as MyGnokki2- is a full-featured cellphone manager for *nix and Win32. Its makefile knows about .debs and .rpms, it is incredibly easy to configure and -unlike Gnokii- it supports the Nokia 3200 (RH-31) right out of the box through an inexpensive DKU-5 cable.
Right now I’m using this simple /etc/gammurc under Debian GNU/Linux with kernel 2.6.12:

port = /dev/ttyUSB0
model = 3200a
connection = dku5fbus
synchronizetime = yes
#logfile = gammulog
#logformat = textall
use_locking = yes
gammuloc = locfile
startinfo = yes
gammucoding = utf8
rsslevel = teststable
usephonedb = yes

# gammu --identify duly reports

Manufacturer  : Nokia
Model         : 3200a (RH-31)
Firmware      : 5.29 I (22-10-04)
Hardware      : 1620
IMEI          : 356656xxxxxxxxx
Original IMEI : 356656/xx/xxxxxx/x
Manufactured  : 06/2005
Product code  : xxxxxxx
Simlock data  : xxxxxx
Old simlock   : TELCEL GSM (xxx xx)
UEM           : xxxx

Find out LDAP client IPs is a simple perl filter that processes SunONE Directory Server 5.2 access logs to find out the IP addresses that queries are coming from. It’s very useful to evaluate the impact for migrating LDAP infrastructures. Most comments and variable names are in spanish but the code should be clear enough to any SODS sysadmin. Or drop me a line if you absolutely need an all-english version.

# $Revision: 1.1 $
# Analiza archivos access de Sun ONE Directory Server 5.2 para generar
# reporte de IPs de clientes y servidores
# Copyright (C) 2005 Javier Arturo Rodriguez
use strict;
my $filename = shift @ARGV;
die("Usage:\t$0 <filename>\n\tbunzip2 -c <filename.bz2> | $0 -\n") unless $file
while(<FILE>) {
        if($_=~m,^\[(.*?)\].*?connection from ([\d\.]+) to ([\d\.]+),) {
foreach my $dst (sort keys %{$acceso||{}}) {
        print "Acceden a traves de $dst\n";
        foreach my $src (
                reverse sort { $acceso->{$dst}->{$a}->{CNT} <=> $acceso->{$dst}
->{$b}->{CNT} }
                keys %{$acceso->{$dst}||{}}
        ) {
                printf("  %-15s (last seen on %s; %d hit%s)\n",


Mitigate the .WMF vulnerability with Exim, Squid and SquidGuard

Unless you’ve been on holiday leave you’ve probably heard about the WMF vulnerability by now. Everything seems to indicate that Microsoft won’t take action to patch this gaping hole before January 9th, so here are a few measures to be on the safe side.

1. Before you do anything else, go ahead an unregister SHIMGVW.DLL

C:\> regsvr32 -u %windir%\system32\shimgvw.dll

Put this in a login script, and just for good measure go ahead an run it in every Windows box you’re responsible for. Heck, run it even in those you’re *not* responsible for as well.

2. I already got quite a few .WMF attachments on the spamtraps. F-Secure has a very interesting specimen and a lot to say about it. So the next step is to block them in exim.conf. Enable the acl_check_content ACL and make sure that you have a rule like this one:

  deny  message = This message contains an unwanted file extension ($found_extension)
        demime = scr:vb:vbs:vbe:js:jse:reg:bat:lnk:pif:hlp:dll:com:rar:wmf

3. SquidGuard can filter URLs that match a given regular expression. Add these regexes to a local-blocks/expressions or similar file:


Note that the .dll and .js extensions aren’t blocked for HTTP. That’s because the lovely IIS uses the .dll suffix for its extensions, and you can’t block JavaScript for HTTP either unless you want to break 90% of the Internet for all your local clients. I firmly belive that blocking them for FTP is just fine, tough.
Update 20060102 125530: Jeremy Gaddis shares a squid recipe.

Of course, this only applies if you use exim and Squid+SquidGuard -which by the way are all excellent Open Source products- but the same principle applies to any other mail and proxy servers. If you implement all three recommendations you should be fine. User should not get .WMF files through email or the Web. Even if a clueless user catches it though some other means (IM, external e-mail account, a *ack!* floppy disk/CD-ROM/flash drive, a helpful colleage, etc.) the REGSVR32 workaround should keep the exploit at bay. If you definitely need to work with WMFs, there are other alternatives as outlined by Richard Bejtlich. Just don’t hold your breath for a Microsoft-backed patch.

<rant>And about Microsoft’s “swift” response to this issue: The next time that someone gives me the line about not using Open Source because there’s nobody to take responsibility for problems, I’ll puch him in the face without further warning.</rant>