Life and all that

I’ve recently been working on a personal project to set myself up a fileserver with redundant storage, and I thought I’d combine this with a desire to run my own installation of Myth TV. In the house I’m currently living in, my room is in the attic and the only aerial input is fed into the living room, Myth seemed like the perfect way of distributing the television upstairs without cables, and theoretically should plug directly into the XBMC install I have running on an Asus Revo R3600 I have upstairs.

So this is detailing my experiences, the problems I’ve come up against, and the potentially rubbish ways I’ve come up with to deal with them. The end result however, is something that appears to be working, and whilst I can’t vouch for the success of my redundant storage solution till I have to use it in anger, it seems to be functioning as expected.

Step Zero: Mythbuntu

I chose to go with the pre-built Myth distribution of Ubuntu. I presume that most of these instructions would work for any debian based flavour of Linux (and with a bit of thought probably any other distro) but I didn’t have to manually install any of the myth software, and my hardware was all auto detected. I suppose in some cases you wont be so lucky.

One small issue I think I came across, I installed the OS and then found that GRUB couldn’t find the master boot record and it refused to boot. I think this was because the system disk wasn’t the first one seen by the BIOS. I just switched my SATA connectors around until it was, and reinstalled from scratch. Not the perfect answer, but it worked and that was my goal

Step One: Software Raid

I used mdadm to handle the RAID, and this wasn’t pre installed in Mythbuntu so first of all, get it installed.
$ apt-get install mdadm

In my machine I started off with two 1.5Tb hard disks, alongside the system disk, which I wanted to set up as a paired raid10 array. I searched dmesg to find the device names of the two disks first.
$ dmesg | less

Piped the output of dmesg into less, then searched that output for references to the one disk I knew I had, the system disk ’sda’.
'/sda'

This showed me sdb and sdc, which I guess you’d think was logical, but I was being paranoid. You can also see the devices listed in /dev/.

Here was my magical command :-
$ mdadm -v --create /dev/md1 --level=raid10 --raid-devices=2 /dev/sdb /dev/sdc

Verbosely create a new raid 10 device called /dev/md1 (I should have used md0 if I were being correct but I didn’t, meh), using two raid devices found at /dev/sdb and /dev/sdc. You can test this is working with :-
$ mdadm --detail /dev/md1

And again, the device should appear in /dev/.
You can check the progress of the raid array being initialised with :-
$ cat /proc/mdstat

And you can see the raid array appearing as one disk, by using :-
$ cfdisk / dev/md1

Though this may not work as expected if the disks you’ve used already had some form of file system on them, unreadable by Linux.

Technically there is another step which goes here, but I’m writing this to include the problems I faced, as I faced them; skip down to ‘Problems after Reboot’ if you want to spoil the surprise.

Step Two: LVM

Initialise the disk for LVM.
$ pvcreate /dev/md1

Creates the a volume group, containing that ‘disk’.
$ vgcreate vg-server1 /dev/md1

Now, create the volumes themselves! I decided I wanted two, one partition for mythtv, the other for data.
$ lvcreate -L 500g -n lv-mythrecordings vg-server1
$ lvcreate -L 895g -n lv-data vg-server1
I had a ‘1.5Tb’ disk, which of course ends up being nowhere near 1500gb. Hence I chose 500gb for my myth partition, and what was left at this point for data.

Next I needed to put a filesystem on the partitions. I chose XFS as it is extendable while mounted, very easily, but it has the drawback of not supporting shrinking. I don’t think I’m ever going to need to make my partitions smallers, so that’s fine by me.
$ apt-get install xfsprogs
$ mkfs.xfs /dev/vg-server1/lv-data
$ mkfs.xfs /dev/vg-server1/lv-mythrecordings

In order to test this had worked I mounted the partitions, and wrote small text files to them.
First of all, create the mountpoints (I did this in /mnt for convention purposes at this point) :-
$ mkdir /mnt/data
$ mkdir /mnt/mythrecordings
$ mount /dev/vg-server1/lv_data /mnt/data
$ mount /dev/vg-server1/lv_mythrecordings /mnt/mythrecordings
When mounting you need to refer to the ‘magical’ device address, you can see how it works there.
Also, if you mount these as root (i.e. sudo) you can only write to them as root. Expect to have to sudo when creating your test files.

Step Three: fstab
We don’t want to have to mount the partitions by hand every time, it’d be ridiculous. The solution is to add them to fstab.

My editor of choice is vim, but any text editor will do :-
$ vim /etc/fstab
You may wish to make a copy before you edit this file, just in case you change something by accident.
I added :-
/dev/vg-server1/lv-data /raid/data xfs defaults 0 0
/dev/vg-server1/lv-mythrecordings /raid/mythrecordings xfs defaults 0 0

The ‘defaults’ option means certain interesting things to do with the way in which the partitions are mounted. The default was fine by me, read up on it if you think you may need something more complex.

Now create folders for the mount points to match fstab. I chose to keep my partitions mounted in /raid – something I just chose myself, no convention.
$ mkdir /raid/data
$ mkdir /raid/mythrecordings

I then tested fstab by mounting them as they should be when the system boots :-
$ mount /raid/data
$ mount /raid/mythrecordings

When mounted, you will need to check the permissions on the folders are correct for everything to have permission to read/write to them, and that they are owned by the right user / in the right group. This involves the commands ‘chmod’ and ‘chown’.

Step four: Samba

Now samba for remote access to the partitions as shares, from Mac OS and Windows (and Linux).

$ apt-get install samba smbfs

Then you just add things to the config file. Again, make a copy if you’re worried you might mess it up.
$ vim /etc/samba/smb.conf

Under global settings I put :-
security = user

And then I added my shares :-
[media]
comment = Media Share
path = /raid/data/media
browseable = yes
read only = yes
guest ok = yes
write list = sara

[unsorted]
comment = the unsorted directory
path = /raid/data/media/Unsorted
browseable = yes
writeable = yes
guest ok = yes

[files]
comment = Files Share
path = /raid/data/files
browseable = no
read only = yes
guest ok = no
read list = sara
write list = sara

[sab]
comment = sabnzb space
path = /raid/data/sab
browseable = no
read only = yes
guest ok = no
read list = sara
write list = sara
These may not be exactly right, but they seem to work for me. Notably, [unsorted] is a dump directory. Guest is allowed to write to it, to allow housemates who I don’t trust to organise things properly to leave things for me to assimilate into the media collection. [media] is readonly for guest accounts (i.e. they are allowed to read it, and access what’s there, but they can’t mess anything up). [files] and [sab] are shares only for me, they don’t appear in a network browser and only I have access to write.

Lastly, whichever account you’ve specified as having access, you need to give it a samba password.
$ smbpasswd -a sara
New SMB password:
Retype new SMB password:
Added user sara.
This only works for user accounts which exist on the host machine.

Step five: Problems after Reboot

Having got this far, I turned off the machine to connect my second pair of hard disks. On booting the machine up, the raid device /dev/md1 was nowhere to be seen but I could see that /dev/sdb and /dev/sdc still existed.

I tried to manually start the raid array first of all :-
$ sudo mdadm -A /dev/md1 /dev/sdb /dev/sdc
[sudo] password for sara:
mdadm: cannot open device /dev/sdb: Device or resource busy
mdadm: /dev/sdb has no superblock - assembly aborted
Obviously wasn’t successful.

So, I wanted to check that the disks still knew they were meant to be part of an array :-
$ sudo mdadm --query /dev/sdb
/dev/sdb: is not an md array
/dev/sdb: device 0 in 2 device undetected raid10 /dev/md1. Use mdadm --examine for more detail.
$ sudo mdadm --query /dev/sdc
/dev/sdc: is not an md array
/dev/sdc: device 1 in 2 device undetected raid10 /dev/.tmp.md1. Use mdadm --examine for more detail.
This made me breathe a little easier.

In the end, the solution was to create a mdadm config file. And it turns out it comes with a nice little script to generate just that :-
$ /usr/share/mdadm/mkconf>/etc/mdadm/mdadm.conf

A reboot showed this had worked quite nicely.

Step Six: Adding more disks

I connected up my new disks, and I checked again in dmesg that they were being seen. I then double checked using mdadm that the disks i was about to raid, weren’t the previous disks being detected in a different order.
$ mdadm --query /dev/sdb
/dev/sdb: is not an md array
/dev/sdb: device 0 in 2 device active raid10 /dev/md1. Use mdadm --examine for more detail.
$ sudo mdadm --query /dev/sdc
/dev/sdc: is not an md array
/dev/sdc: device 1 in 2 device active raid10 /dev/md1. Use mdadm --examine for more detail.
$ sudo mdadm --query /dev/sdd
/dev/sdd: is not an md array
$ sudo mdadm --query /dev/sde
/dev/sde: is not an md array

This quelled my paranoia, so I went on to create the array :-
$ mdadm -v --create /dev/md2 --level=raid10 --raid-devices=2 /dev/sdd /dev/sde

And as before, add it to lvm :-
$ pvcreate /dev/md2
$ vgextend vg-server1 /dev/md2
This extends the volume group from earlier to now include this new hardware.

I unmounted the current shares I want to extend:-
$ umount /raid/data
Incidentally, smbstatus will tell you who/where is connected to the samba shares if you need to know.

$ lvextend /dev/vg-server1/lv-data /dev/md2
This extends the volume itself to include the maximum space available on the new disk.

Now, to grow the filesystem. The scary bit. XFS can only grow when mounted, so I remounted the share. Then grow the fs by referring to the mount point.
$ xfs_growfs /raid/data

Phew. I then ran lvscan to look at my volumes and their sizes :-
$ lvscan
ACTIVE '/dev/vg-server1/lv-mythrecordings' [500.00 GB] inherit
ACTIVE '/dev/vg-server1/lv-data' [2.24 TB] inherit
Success!

Step seven: A few tips on making myth frontends work with a remote backend

You need to make sure that myth-backend is set to refer to it’s external address, not localhost or 127.0.0.1. This is because when frontends connect, the backend tells them that address to talk to for video.
Also, don’t be foolish enough to try using MDNS (i.e Bonjour) for this. I had my external address set to ‘computername.local’ which works perfectly for every communication I would normally do. Unfortunately, it caused the official myth-frontend for OSX to fail to connect to the backend 9 times out of 10.

I found XBMC to be much, much nicer and more sensible. In order to add myth to it, you need to create a new source like this
myth://mythtv:YOURPASSWORD@mythbackend-pc
Make sure the password is the one from the myth-backend config, it is randomly generated.

Lastly, I got XBMC connected, it would show me the programme guide, and see a list of recorded programmes, as well as a list of live channels. Everything looked great, but when I tried to play any video it would either do nothing, or give me an error telling me ‘playback failed’ and asking me to check the logs.

Solution? Edit /etc/hosts, and add the fileserver by hand. Madness.

The End
I hope maybe this will help someone out there, it isn’t a perfect method and I’m sure I’ve done things in ways which could be improved, but it works and I am happy with it. I’d suggest if anyone has questions, I’m not the first person to turn to, I’ll only google for the answers!