No-downloading inconveniences in the digital age

My country does not allow me to download music/movies for personal use!

While a good number of countries (e.g., The Netherlands, Switzerland) have relatively sane laws that allow the downloading (though not uploading) of music and movies, there are a good number of other countries where even the downloading of music and movies for personal use is forbidden.

Even if one does live (or operates a server) in one of the latter countries, these restrictions are but small inconveniences that are easily worked around.

Case in point here is an Ubuntu Linux server in one of these countries to which somebody wants to download content from the Giganews Usenet provider, where one sets up OpenVPN himself. Note that although this article is written in terms of Linux and Giganews, the general principles readily carry over to other situations.

The solution: OpenVPN

The solution in this case is to hide the fact that your are perusing the service from the country with the backward laws that you happen to be in. A simple mechanism to do this is to use OpenVPN: ones creates an encrypted VPN tunnel over which one tunnels the connections to Giganews.

If one already has an account at Giganews, Giganews offers a branded deal through VyprVPN where you get OpenVPN access for $5 per month.

Step 1: Apply for OpenVPN access at Giganews

Just follow the steps on their website: you can't go wrong there.

Step 2: Install OpenVPN

sudo apt-get install openvpn

(easy enough)

Step 3: Install the VyprVPN root certificate

sudo wget -O /etc/openvpn/ca.vyprvpn.com.crt http://www.giganews.com/vyprvpn/ca.vyprvpn.com.crt

This allows your OpenVPN client to ascertain that it is indeed talking to VyprVPN, and not to some man-in-the-middle attack box your government may have put in place.

Step 4: Create a configuration for your VyperVPN

The easiest way to do this is to create two files: one that contains your Giganews username and password, and one that contains the OpenVPN client configuration. The names are arbitrary, but I happen to use these:

/etc/openvpn/vyprvpn.pass contains:

gn123456

abcd1234

(replace the red content with your actual username and password).

/etc/openvpn/vyprvpn.conf contains:

client

dev tun

proto udp

remote eu1.vpn.giganews.com 1194

resolv-retry infinite

nobind

persist-key

persist-tun

persist-remote-ip

ca ca.vyprvpn.com.crt

tls-remote eu1.vpn.giganews.com

auth-user-pass vyprvpn.pass

comp-lzo

verb 1

(you could replace the eu1 part with several other options, but eu1 is in the Netherlands, where downloading is legal).

Step 5a: Fire and forget

Open boot, your server will now automatically start up your VyperVPN, and route all traffic through it. You can also force it right now by issuing:

sudo /etc/init.d/openvpn restart

If that is not what you want, e.g., because you use the box for other purposes, too, the next step will describe how to route just your Giganews traffic through the VPN.

Step 5b (optional): Route just Giganews traffic through the VPN.

If this is what you want, this is possible, too. Simply add the green content to your /etc/openvpn/vyprvpn.conf file:

client

route-noexec

route-up /etc/openvpn/vyprvpn-route-up.sh

down /etc/openvpn/vyprvpn-route-down.sh

script-security 2

dev tun

proto udp

remote eu1.vpn.giganews.com 1194

resolv-retry infinite

nobind

persist-key

persist-tun

persist-remote-ip

ca ca.vyprvpn.com.crt

tls-remote eu1.vpn.giganews.com

auth-user-pass vyprvpn.pass

comp-lzo

verb 1

The route-noexec option tells OpenVPN to not directly use all route pushes it gets from the VyprVPN server, but to pass options via environment variables to scripts in which you are in control of what happens.

In my case, I wanted to use news-europe.giganews.com for downloading. I used whois to figure out that their IP range in Europe is 216.196.96.0/19. The two scripts mentioned above now contain:

/etc/openvpn/vyprvpn-route-up.sh:

#!/bin/bash

# Route Giganews Europe (216.196.96.0/19), and ONLY Giganews,

# through VyprVPN.

ip route add 216.196.96.0/19 dev $dev

(note that $dev is passed in the environment by OpenVPN).

/etc/openvpn/vyprvpn-route-down.sh:

#!/bin/bash

# Remove routing for Giganews Europe (216.196.96.0/19).

ip route del 216.196.96.0/19

Step 6: Check that things work

Quickly check that your routing to Giganews indeed goes through the VPN:

traceroute news-europe.giganews.com

traceroute to news-europe.giganews.com (216.196.109.144), 30 hops max, 60 byte packets

 1  10.25.0.1 (10.25.0.1)  14.601 ms  14.606 ms  14.611 ms

 2  * * *

 3  vl304.gw1.ams.giganews.com (216.196.108.218)  15.268 ms  15.309 ms  15.274 ms

 4  news-europe.giganews.com (216.196.109.144)  14.964 ms  15.195 ms  15.210 ms

Here, the first hop being on a private subnet (10.25.0.1, on 10.0.0.0/8, which is private) tells you that traffic is routed correctly.

Happy networking!

Local-disk encryption to protect against casual privacy loss

Like many others, I store a lot of privacy-sensitive information on the disks of my local server: photos, scanned documents, and more. I do not feel the need to protect that data from those who have physical access to the machine, let alone to protect that data from authorities, should those ever come along with a (mistaken) warrant. No, the protection I seek is much simpler:

The protection I would like is against those who get one of my disks, for example when I exchange a disk under warranty. It would not be the first time that such a disk is resold, or that the friendly shop personnel scan the disk for interesting data. Also, my other server, which sits in a remote datacenter, should not leak information when a disk is exchanged.

The simple mechanism by which I now do this is by accessing the underlying disks (or partitions) of my data disks through dm_crypt , and to create zpools, mdraid, or simple filesystems on top of those dm_crypt mapped block devices. The normal way to do this is to add the required entries to /etc/crypttab, but I find that Ubuntu sets up these devices too late in the game. Therefore, I created my own script.

On my remote server, I have a script in /etc/init.d/local-cryptsetup , which contains:

#!/bin/bash

/sbin/cryptsetup -d /etc/mydevs/passwd.dat create zloop0 /dev/disk/by-id/[NAME_DISK1]

/sbin/cryptsetup -d /etc/mydevs/passwd.dat create zloop1 /dev/disk/by-id/[NAME_DISK2]

In /etc/rc2.d, /etc/rc3.d, /etc/rc4.d, and /etc/rc5.d, I symlink a link called S05local-cryptsetup to the above script. I chose the number S05, as I use these mappings are underlying devices for a ZFS ZPool, and the ZFS subsystem is started at S20. As S05 < S20, this ensures that the mappings are available before ZFS attempts to start using them.

Initializing the ZPool once was easy enough:

# zpool create tank mirror /dev/mapper/zloop0 /dev/mapper/zloop1

I ensures that the pool, and all data in it, successfully survive a reboot.

Hot-removing a SATA drive, and copying partition tables

In a multi-disk setup, one sometimes needs to replace a drive. If one has a hot-swap bay, this is surprisingly easy, but before actually pulling the drive out, one MUST tell Linux that one is about to do so:

# echo 1 > /sys/block/sdX/device/delete

You can then pull the drive out and replace it with a new one. Note, though, that the new drive will generally get a new device name (e.g., /dev/sdZ), until the next reboot.

Now, say that you want the drive to have identical partitions to another drive (say, sdY) in your system, then you simple copy the partition tables:

# sfdisk -d /dev/sdY | sfdisk /dev/sdZ

This can all be done without ever rebooting the system :-)

A _seriously_ close shave with Linux software RAID

I am running a 4-disk home server that uses the first partition on each of the four drives as a single RAID6 array using Linux mdadm software RAID. As I freed up some partitions on the remainder of each of the drives, I wanted to extend the size of the first partition on each drive so that I could first grow the RAID6 array, and then grow the filesystem.

That sounded easy enough: my data drivers are /dev/sdb, /dev/sdc, /dev/sdd, and /dev/sde, so I simply first checked what the starting sector of each partition was, using:

# fdisk -c -u -l /dev/sdb (and for c, d, and e, too).

This showed that the first partition started on block 2048. Fair enough: I ran

# fdisk -c -u /dev/sdb

deleted (d) partition 1, created a new partition 1 with a new end block (higher than before), and set the type to Linux Raid Autodetect (fd).
I did the same on /dev/sdc, /dev/sdd, and /dev/sde, too.

Of course, since the array (/dev/md0) was still active and mounted, the kernel refused to re-read the partition table. That was fine: a reboot would solve that.


I rebooted, and to my dismay I found out that the array was no longer recognized! It turned out that my little fdisk adventure removed the RAID superblock, and I did so on ALL RAID6 members. That is slightly problematic: having even as little as one superblock still available is enough to use "mdadm --examine --scan" to get things up and running again, but I had NONE left.

You can imagine my sinking feeling as I realised that I might just have lost 1.2 TB of private data... What to do? All options of mdadm --assemble would not work, for lack of superblocks, and completely recreating the array would destroy all data, right?

Right?...

Wrong! It turns out that mdadm has a few nice cards up its sleeve... If you create an array with the bare minimum number of devices (N-2 for RAID6, N-1 for RAID6, 1 for RAID1), there is nothing to sync, and mdadm will not do so. Now, in RAID6 (and RAID5), the order of the devices is important (because of the data/parity-block rotation), so with my bare minimum of 2 devices, I made a list of all possibilities. If you call the two devices /dev/sd${X}1 and /dev/sd${Y}1, I had the following possibilities:

X Y
----
B C
B D
B E
C B
C D
C E
D B
D C
D E
E B
E C
E D

For each of these combinations, I ran:

# mdadm --create /dev/md0 --verbose /dev/sd${X}1 /dev/sd${Y}1 missing missing

(note the two missing devices at the end)

If that succeeded, I tried to run a filesystem check:

# fsck.ext4 /dev/md0

For most of the options, the block ordering would be wrong, so fsck.ext4 would not find a filesystem, so I would delete the array again using:

# mdadm --stop /dev/md0

I thus went through all the options, becoming more and more nervous, until the LAST option (seriously!) was right! :-) The filesystem was nicely checked, and then I could mount it, too:

# mount /dev/md0 /data

Of course I was running at the bare minimum of devices now, so I added the other members back in:

# mdadm /dev/md0 --add /dev/sdb1 /dev/sdc1

Linux does this one new device at a time, which takes 10 hours per device (it is 1.3 TB per device). I let it run overnight. When I looked in the morning, adding the first device had succeeded (putting me in the safety of N+1 redundancy already), and Linux was resynching the last device.

That was a close shave, in fact, _way_ too close for comfort! I'll be looking at a hardware RAID HBA next.

Put an IcyBox into my server

Because my server had become a bit of a mess on the inside (4 SATA drives), I bought an IcyBox IB-553SK to at least fit 3 of the drives neatly into the 2 5.25" bays that the server box has.

This looks a lot better now.

Installing Kubuntu/Ubuntu 9.04 on an Acer Aspire 3000

Yesterday, I installed Kunbuntu 9.04 on a family member's Acer Aspire 3000 laptop; my family member was fed up with Windows constantly crashing and being slow.

Things worked out-of-the-box, except for two small things:

1. The display colors were garbled.
2. The wireless network card did not work.

Both were easily solved though:

1. Edit /etc/modules, and add a line containing "sisfb"
2. sudo apt-get install b43-fwcutter

Reboot, é voila, everything works!

Recovering from a bricked Netgear EVA8000 in Linux

I have done dozen of firmware upgrades on many devices over the years. Despite all the warnings about bricked devices, nothing bad ever happened to me when flashing firmware. That is, until I bricked my Netgear EVA8000 media player on its upgrade to firmware 2.1.83 this weekend...

The unit would indicate that it was applying the upgrade, advance to about 70% completion, and then just switched off on me. Any attempt to switch it back on afterwards failed.

Fortunately, Netgear has a recovery procedure for this type of event, and a HOWTO is here. This should work out-of-the-box on Windows, but my laptop runs only Ubuntu.

No problem though: I managed to unbrick the unit from Ubuntu, like so:

1. Pull the power plug on your EVA8000


2. Download the recovery tool from here, as indicated on the HOWTO page.


3. Install a TFTP server on your computer. I used the tftpd-hpa package:
   
   • sudo apt-get install tftpd-hpa
   • sudo vim /etc/default/tftpd-hpa
   • change the "no" field after the line starting with "daemon" to "yes".
   • sudo /etc/init.d/tftpd-hpa restart


4. Unzip the recovery zip file, and copy the eva-recovery-image.bin file to the TFTP server's root directory:
   
   • unzip eva8000_recovery_tool_2_0_159_uk.zip
   
   
   • sudo cp eva-recovery-image.bin /var/lib/tftpboot
   
   
   
   


5. Change the IP address of your computer:
   
   • sudo ifconfig eth0 10.23.23.200


6. While depressing the EVA8000's reset switch, stick its power cord back in. The unit will download the recovery file. After about 4 minutes, it reboots and all is fine.