by siyb

Over a year ago I installed the first harddrive upgrade on Sycorax, the siyb.de server. (Un)fortunately harddrive space doesn’t last forever, so that recent events forced me to upgrade the storage hardware once more. Due to a lack of money I choose to use mdadm to create a software raid above 4 newly purchased harddrives that have been connected to a PCI SATA II controller, anything else would have force me to buy a new motherboard, CPU and RAM.

Ingredients:

• 1* SATA Controller PROMISE SATA300 TX4
• 4* SAMSUNG SATAII 750 GB F1

Although I am really happy with my Seagate harddrives that I have used in the first Raid, I have chosen to use Samsung hdds this time because they are quiet, cool and supposedly last for a long time (we will see :>). This report will feature hardware assembly as well as setup of the encrypted software raid.

First of all I had to prepare the server for the new hardware by connecting an additional cable to my Enermax Liberty ELT400AWT and installing an extra fan, to cool the hdds, that would be placed above one another and therefore require some active cooling.

After installing the controller card the hdds could be connected and the machine was ready to be turned on again

Lets build the raid, I found some good tutorials online that helped me setting up the mdadm raid, they can be found in the appendix. I suggest that you take a look at them if you are planning to create a software raid yourself, my notes are just “guidance” and a small reference, but I will not going to explain any little detail. Anyway, here is what I did (Debian Lenny, standard Debian kernel in use):

Installation of required packages:

apt-get install hashalot cryptsetup mdadm

Software raids consist of partitions rather than physical devices, so naturally the first thing to do was to create partitions on the new drives that I could use to assemble a raid, I choose to use cfdisk for comfort, but you might as well consider fdisk or other tools.

cfdisk /dev/sdb
cfdisk /dev/sdc
cfdisk /dev/sdd
cfdisk /dev/sde

I created one partition per drive, which left me with a total number of 4 partitions to use with my raid5.

mdadm –create /dev/md0 –level=5 –raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

Before formatting the raid device /dev/md0, I took some time to encrypt the device:

cryptsetup –verbose –verify-passphrase luksFormat /dev/md0

After that formatting is a piece of cake

cryptsetup luksOpen /dev/md0 cryptraid
mkfs.ext3 /dev/mapper/cryptraid

Adding the following lines to /etc/fstab and /etc/crypttab allows the device to be mounted automatically when starting the computer

In /etc/crypttab:
cryptraid /dev/md0 none luks

In /etc/fstab:
/dev/mapper/cryptraid /mnt/storage ext3 defaults 0 0

The result:

/dev/mapper/storage 2063G 13G 1945G 0.7 [………………………………………………………….] /mnt/storage

• Linux Wiki - mdadm
• Rebuilding software raids
• Linux Home Networking - Linux Software Raid howto

by siyb

Eight days after the release of version 1.1, version 1.2 has been completed and may be acquired from our Debian depot or its git repository. The plugin loader as well as the clientsettings option window have been remodeled and plugins are now provided as special formatted tarballs that can be easily installed using the well known plugin installer. Additionally, the IRC away system has been fully implemented now and is therefore ready to be used.

Some nasty and pretty annoying bugs have also been fixed, for instance, all channelflags will be excluded from the nick autocompletion now. For a full list of changes, bugfixes and additions please take a look at the changelog. Windows users will not be able to run this version of tIRC, I simply do not have enough time to modify the code so that it is fully windows compliant.

The platform independence of tIRC defiantly is an important matter, as the client was in fact designed to run on many different platforms, but ever since the introduction of the trayicon and the trayicon flashing mechanism in particular, platform independence was at stake, due to the two completely different approaches of winico, that relies on the windows api and Freedock. The tIRC project is therefore looking for a windows maintainer / packager that is capable of fixing windows related issues within the tIRC code as well as creating full installer packages, for one click installations.

If you are an interested, capable and motivated windows user, that is willing to invest some time and sweat creating a tIRC windows port please let me know. In the meantime, if you are using Windows and want to run tIRC you will have to find a workaround yourself, submit your patch if you did :>.

by siyb

UPDATE: Debian depot on mount.at and tIRC v1.0_Final

by siyb

We decided to upgrade the hardware on mount.at today and therefore had to shutdown the server for several hours. Hades is running again now, but not all services are restored to their full extend, the jabber server (jabber.mount.at) has been recovered already and should be usable again. Due to the fact that the bootloader was installed on a hdd that had a total breakdown and I/O errors that prevented a reinstallation of bootloader on the system drive, we had to setup the server again.

The main problem was that our backups of the Mnesia database where outdated, they had to be recovered from the old hdd (the one not broken :>). This procedure turned out to be far more complicated / frustrating than expected. Due to the fact that the control interface ejabberdctl relies on RPC, which require a valid hostname to function properly, the recovery wasn’t as simple as calling the program from the host we connected the old harddrive to. I wrote a small howto for anyone stuck in the same situation:

Solution: chroot

Mounting the harddrive

mkdir /mnt/hdd && mount /dev/sdaX /mnt/hdd

Mounting proc

mount -t proc proc /mnt/hdd/proc/

Change the hostname on the box to the hostname of the machine Mnesia was used on (changing the hostname within the chroot didn’t work), this is necessary because RPC will not work if you do not use the hostname of your old box

$editor /etc/hostname

Chrooting

chroot /mnt/hdd

Starting up the ejabberd daemon and executing backup procedure

/etc/init.d/ejabberd start && ejabberd_ctl backup /tmp/ejabberd.backup

Exit the chroot and copy the backup from /mnt/hdd/tmp/ejabberd.backup to the box you wish to apply it to, use

ejabberd_ctl restore /tmp/ejabberd.backup

to finally restore the backup …

You may need to follow this tutorial when porting the database to a host with a different hostname -> http://www.ejabberd.im/migrate-host

Mount.at will be unavailable for some time tomorrow as well, because the hardware upgrade could not be finished in today’s session, please stand by and sorry for any inconvenience caused.