Wednesday, 5 January 2011

Encrypted LVM for XEN domUs

The basic idea here is that I want encrypted partitions for my domUs (guests), but not for dom0. The reason for this is that I normally does not have physical access to the machines, so I will need to have the machine boot and start sshd without user interaction.

These notes are from a Debian Squeeze dom0/host, with a single 1TB drive installed. dom0 is not in the LVM. Note that these notes are not XEN nor Debian specific, this is just the solution I went with for running XEN guests in an encrypted LVM on my configuration. You should be able to do similar for pretty much any Linux Distro, with or without XEN.

Install packages
aptitude install lvm2 cryptsetup

Create partition for LVM volume group (vg)

I use cfdisk for this (curses-interface). Basically you need to choose the free space to use, make it a primary parition. I chose tyoe 8E (Linux LVM) for the drive, but I am not sure if this is necessary. Remember to select write in cfdisk before exiting.

For me the parition table looks like this at this point:
Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        3648    29295616   83  Linux
/dev/sda2            3648        3891     1951745    5  Extended
/dev/sda3            3891      121601   945510624+  8e  Linux LVM
/dev/sda5            3648        3891     1951744   82  Linux swap

At this point I had to reboot to actually be able to do anything with sda3. This might be due to some XEN magic I don't understand yet. If I understand correctly dom0 has access to most hardware, but must be given so through the XEN hypervisor.


Create and unlock an encrypted container

We need to create something called an encrypted container for the LVM, which basically is what makes encryption happen for the LVM

Create encrypted container
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sda3

You will be asked to give a password, which needs to be remembered/written down. This will be required each time you want to unlock the encrypted LVM (after every boot). Now this container will be locked by default so we will have to open it (you will be asked for the passord):

Unlock encrypted container
cryptsetup luksOpen /dev/sda3 crypt

Set up LVM

With the encrypted container we can actually set up/use the LVM

Create a Physical Group
root@moonlight:/home/zerqent# pvcreate /dev/mapper/crypt
  Physical volume "/dev/mapper/crypt" successfully created
Create a Volume Group (vg)
root@moonlight:/home/zerqent# vgcreate vg /dev/mapper/crypt
  Volume group "vg" successfully created

Ready for action

You are now ready to create Logical Volumes (lv)s. Remember that you will have to unlock the lvm after each boot, or if you lock it.

Unlock LVM after boot
/sbin/cryptsetup luksOpen /dev/sda3 crypt
vgscan --mknodes
vgchange -ay

Application with XEN

Performance wise the net tells me that XEN guests running on LVM as opposed to images (files) is better. With this setup you will have to unlock the LVM exactly once if dom0 needs to reboot. Alternatives for this setup could be encrypted Volume Groups, encrypted-LVM-in-LVM (e.g. during install of guest you create an encrypted LVM which actually already resides in the LVM exposed by the XEN hypervisor).

Security considerations

What security gain you get from this is somewhat questionable. If Dom0 is compromised and the LVM is unlocked you get none. Also a running system with the LVM unlocked will have to store the encryption key somwhere, so this could be compromised. However if someone should steal your computer I deem it unlikely that they will recover anything from the encrypted LVM. These thought are of course based on the understanding that you do not generate, nor store the key to unlock your encrypted drives on the same computer as the LVM resides.

XEN on Debian Squeeze host/Dom0

I wanted to try XEN during the holidays, on a box placed at my parents. Since my experience with XEN was non-existent I was looking forward to a nerdathlon. However, the process turned out to be quite easy and painless.

These notes are based on a standard Debian squeeze minimal install.

Install XEN
aptitude install xen-linux-system-2.6.32-5-xen-amd64

This will install both the XEN hypervisor and a XEN-compatible kernel. However, if you reboot at this stage you are not be running the XEN hypervisor, only a XEN-compatible kernel. We need to modify grub.

Modify Grub2 boot order(From Debian Wiki)
mv -i /etc/grub.d/10_linux /etc/grub.d/50_linux
update-grub2

A good idea is also to prevent grub from probing for operating systems, since this might reveal our guest OSes (DomUs).

Disable Grub2 OS-probing (From Debian Wiki)
echo "" >> /etc/default/grub
echo "GRUB_DISABLE_OS_PROBER=true" >> /etc/default/grub
update-grub2

The various howtos I have found on the subject around the internet also suggest that you enable network bridging in XEN at this point. I doubt this is needed to get networking for Dom0, but I have not tested it.

Enable network briding (From Debian Wiki)
# Uncomment the following line in 
# /etc/xen/xend-config.sxp
(network-script network-bridge)

Reboot at this stage and you will be met with a Debian Squeeze Dom0 running on the XEN hypervisor.

Saturday, 27 November 2010

Control Spotify from XBMC with Mopidy

Update: How well does this work - not very good (with XBMC). Seems that the client in XBMC pretty much doesn't work with Mopidy - sadly. Information available here.

What to Expect from this:

  • If you add and play songs from gmpc, they will play and be visible playing in XBMC
  • The queue in XBMC will not show any songs, except the one playing. But items added to queue in XBMC will actually be added
  • If you control Mopidy from XBMC the song will switch every 5 seconds or so.
  • Using the XBMC client may cause Mopidy to crash - at least it did so for me.
  • Controlling from another client, such as gmpc works fine though, so you can still have a Spotify MPD server =)
I guess most people out there already deleted their MP3-collection and use Spotify or some other means of streaming music. The bad thing is that you really can't use XBMC with such solutions. There was/is some project that tried to implement native Spotify in XBMC, it looks promising and I hope they make it usable. In the mean time, this is my solution to listen to Spotify from XBMC. Note that this requires Spotify premium.


Mopidy

Mopidy is a python MPD server which can use Spotify as a backend. If you don't know what an MPD server is, it basically a media player with many remotes. By that I mean that the audio will stream out from one machine (usually to speakers) but that you can control it from multiple other machines, or locally.


I use Ubuntu Desktop 10.10 32-bit for this install. Basically we follow the install documentation found in Mopidy's documentation.

Install required packages

sudo aptitude install git-core python-alsaaudio python-dev build-essential python-pip

Install libspotify

Note that the 0.0.6 version of libspotify will not work with pyspotify, so for now we need the 0.0.4 version.


32-bit
wget http://developer.spotify.com/download/libspotify/libspotify-0.0.4-linux6-i686.tar.gz
tar zxfv libspotify-0.0.4-linux6-i686.tar.gz
cd libspotify-0.0.4-linux6-i686/
sudo make install prefix=/usr/local
sudo ldconfig

64-bit
wget http://developer.spotify.com/download/libspotify/libspotify-0.0.4-linux6-x86_64.tar.gz
tar zxfv libspotify-0.0.4-linux6-x86_64.tar.gz
cd libspotify-0.0.4-linux6-x86_64/
sudo make install prefix=/usr/local
sudo ldconfig


Install pyspotify
The instructions available at the official website, but are repeated for completeness:

git clone git://github.com/jodal/pyspotify.git
cd pyspotify/pyspotify/
sudo rm -rf build/               # If you are upgrading pyspotify
sudo python setup.py install

Installing Mopidy

sudo pip install Mopidy

Configure Mopidy

Create the following file in ~/.mopidy/settings.py, and place the following contents in it (yes you should replace myusername and mysecret, but the u-at the start should be there)
SPOTIFY_USERNAME = u'myusername'
SPOTIFY_PASSWORD = u'mysecret'

Running Mopidy

Run the command Mopidy, it should report if it can connect to Spotify like this:
zerqent@blitz:~$ mopidy
INFO     -- Starting Mopidy --
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
INFO     Mopidy uses SPOTIFY(R) CORE
INFO     Disabled: mopidy.frontends.lastfm.LastfmFrontend (No module named pylast)
INFO     MPD server running at [::ffff:127.0.0.1]:6600
INFO     Connected to Spotify

MPD Client in Gnome

We need an MPD client to talk to Mopidy, you can look for compatible clients here. In Gnome you can for instance use GMPC.

sudo aptitude install gmpc

Just hit Connect then Forward
Setup of gpmc is pretty simple, just press forward once, then "Connect" and then Forward and Finish. You will probably find this interface somewhat limited compared to Spotify but it does work. You can get your Spotify playlists, you can search, but the browsers might just give you artists that are in one of your playlists or just hang it seems.

GMPC with Mopidy
MPD Client in XBMC
Note that I am assuing that you are using one of the Dharma (e.g. beta/release candidates right now) versions of XBMC, if not you will have to google for an MPD Client.

Navigate to System->Add-Ons->Get Add-Ons -> XBMC.org Add-Ons -> Music Addons and install MPD Client.

From the XBMC root-menu you can reach MPD Client under Music->Add-Ons.




There is really no configuration needed to get the MPD Client to work with Mopidy, since it defaults to the correct settings. So just pick one of the profiles and you should be connected.


Now I haven't used this Client to much so I am not sure how good it is - but it might be a viable solution to trying to control Spotify with vnc or similar.

Remote control of Mopidy

Now one of the reasons you want an MPD-server for serving Music instead of a local music program is that you can remote control it - yes I know this is fully possible with the built-in XBMC web interface, but that doesn't have Spotify-support (yet?).

To allow Mopidy to be controlled from other network units edit ~/.mopidy/settings.py and add:
MPD_SERVER_HOSTNAME = u'0.0.0.0'
Note that this means that everyone can connect to Mopidy, unless you have something else, like a NAT/Firewall, that blocks them. You can limit this more, for that RTFM.