Bye bye Delicious. Hello Evernote!

Well, with Delicious’ death approaching, I was forced to grab all the bookmarks I’ve been collecting in the past 5 years and make a run to another service.

According to some users, Evernote is like a ‘personal assistant’. Since I’ve been needing some assistance with keeping track of all the things going on at the moment, I decided to create an account with the service.

But importing my bookmarks was no easy task, seeing as the people behind Evernote decided to can their Delicious importer citing ‘technical difficulties’. Nevertheless, Father Google was able to point me in the right direction. If you’re on a Mac, check out the excellent Delicious Bookmark Importer for Evernote.

Bear in mind, though, that you’ll probably need a premium account (I did) if you want to import a lot of bookmarks since the script puts the entire link’s page into a note. Otherwise follow the comments on the script’s homepage for instructions on how to optimize it to create notes with only the bookmark’s URL.

Growing a RAID5 array (with LVM) online with MDADM

Trawling through the web I’ve found a lot of information about growing RAID5 arrays, and some sparse information about growing EXT4 partitions. The only problem is they did not appear in the same spots, making this procedure a bit of a guessing game.

I recently decided to upgrade my homebrew NAS. In its original form, it had 2x500GB disks and 2x1TB disks. In RAID5, its capacity is limited to 1.5TB. By replacing the 2x500GB with 2x1TB (totally 4x1TB disks), total capacity expands to a whopping 3TB!

But that’s enough talk, let’s get down and dirty.

General assumptions:

• the disks to be replaced are /dev/sdb and /dev/sdc (array goes from sdb to sde);
• the md array is /dev/md0;
• the LVM is setup as /dev/lvm-raid/lvm0;
• the mount point for the array is /media;
• you are running all this as root; and
• you have three separate backups in case stuff goes wrong.

First of all, we’ll need to replace each 500GB disk in the array individually, and let MDADM rebuild the array after each of the new disks are introduced. To prepare MDADM for the rebuild, set the first disk to be replaced as faulty and remove it. (Don’t worry, it’s not gonna damage it in any way! It’s just the way MDADM works.)

mdadm /dev/md0 --faulty /dev/sdb --remove /dev/sdb

If you don’t have a case with hot-swap HDD trays, turn off your computer, remove the old HDD and add the new one, then turn it back on. The computer should detect it as /dev/sdb as well.

Add the new drive to the array:

mdadm /dev/md0 --add /dev/sdb

Wait until MDADM is finished with the rebuild. You can watch with:

mdadm --detail /dev/md0

Once it’s done, do the same for the other drive. Do not proceed before ensuring the array has all the new drives active (and the rebuild is finished).

Time to grow the array size to its maximum logical limits (from 1.5TB to 3TB) in MDADM:

mdadm --grow /dev/md0 --size=max

Expand the PV:

pvresize /dev/md0

Extend the LV to the maximum available size of the VG:

lvresize -l+100%FREE /dev/lvm-raid/lvm0

Then proceed with the filesystem resize operation:

resize2fs -p /dev/lvm-raid-lvm0

If all went well, you’ll have a lot more space in your mount point (remember, mine is /media) to play with, and your old data is still there! Doing an fsck is a good idea, but that means bringing it offline. And there’s plenty of info out on the web explaining how to do that.

One cool thing to notice is that I replaced the first disk and rebuilt the array while watching an HD movie on the HTPC. No skips, jumps or anything. Pretty cool stuff!

If things turn out different for you, let me know in the comments.

PS1: My original setup didn’t use LVM, and resize2fs wouldn’t work on it. To grow the EXT4 partition, I’d have to turn the computer off and use Gparted. A hassle. That’s when I decided to setup one logical volume (using LVM) on top of the RAID5 array. For instructions on how to setup LVM on RAID, visit this page and check the comments from the author on 19-April-2007 at 16:26.

PS2: After seeing my backup restore write speed never go beyond 10MB/s, I decided to do some tuning to the RAID array. Turns out there is a nice script here. It didn’t fully work for me, so I took the liberty to improve it and you’ll find it here. But take caution, as it needs to be configured for your own array properties before it is called, or all hell breaks loose!

That damn xenserver-linuxfixup-disk.iso!

In case you run into the same problem as me (that is, trying to unplug an already unavailable ISO SR from XenServer 5.6 and finding out that the xenserver-linuxfixup-disk.iso can’t be removed), there’s a way out. Granted, it’s not that easy, but at least it worked for me.

Assumptions taken here: you know how to navigate xe (the console tools of the XenServer host), knows the UUID of the SR (using xe sr-list type=iso) and knows this is all funky stuff that, if done wrong, WILL BREAK things. You’ve been warned.

Firstly, find out the UUID of the VDI (trying to unplug the PBD or the SR through console should give you that):

xe vdi-list name-label=xenserver-linuxfixup-disk.iso

Find the UUID of the VBD (should return only one):

xe vdi-param-get uuid=<VDI_UUID> param-name=vbd-uuids

Find the UUID VM which is using it:

xe vbd-param-get uuid=<VBD_UUID> param-name=vm-uuid

Shutdown the VM (it takes a while, don’t panic and go get a coffee!):

xe vm-shutdown uuid=<VM_UUID>

After that, XenCenter should allow you to Forget/Detach/Destroy the ISO SR, or you can do it through xe:

xe pbd-unplug uuid=<PBD_UUID>

xe sr-forget uuid=<SR_UUID>

The Key to Traffic-based Tickets in RADIUS

I spent ages looking for information on how to limit user access based on traffic used through a captive portal using pfSense, and couldn’t find somewhere with an easy to use SQL command that was generic enough to use with daloRADIUS.

Well, in case you were wandering (like me) around the ‘net, here it is:

SELECT IFNULL(SUM(AcctInputOctets + AcctOutputOctets),0) AS AcctTotalOctets FROM radacct WHERE username = '%{%k}' AND UNIX_TIMESTAMP(AcctStartTime) + AcctSessionTime > '%b';

This, in essence, is the SQL you need to use for the traffic-based counter that you need to setup in FreeRADIUS for this to work. Then add a check for an attribute like Max-Total-Octets and add that attribute with the amount you want to limit (in bytes) to the users who should be limited, and voilà!

You can use a reset value of never and just keep re-filling user’s session traffic when they run out. Set a reply-message that tells them they’ve run out of data, though, or it will just look like they got their password wrong.