CrashPlan Linux: Deleting the Massive Cache

Recently I noticed that I had surprisingly little free space on my root partition.  Some investigation revealed a 6.8GB “/usr/local/crashplan/cache/42” directory.

The fix was pretty easy to find for MacOS, and for convenience I’m reposting the instructions suited for Linux.  Firstly, to quote the page:

CrashPlan does not have the ability to limit the size of the Cache file though you can modify the New Version (every x [time]) setting to help prevent the Cache file from growing to quickly. You can find this setting by opening CrashPlan and viewing Settings > Backup (Sets) > Frequency and versions > New version.

To clear the cache, do the following:

  1. Launch CrashPlanDesktop (from terminal, or, Alt-F2 CrashPlanDesktop)
  2. Double-click the CrashPlan logo in the upper right corner.
  3. In the text input area at the very bottom of the CrashPlan desktop, type: backup.replace 42
  4. Press Enter.
  5. In the text input area at the very bottom of the CrashPlan desktop, type:  restart
  6. Press Enter.

That’s it.  These instructions are close to identical to those in the original post from MacIT Solutions, but I had no need to manually delete the cache directory after the steps above.

The result (after a resync) was a cache directory that was 0.6GB instead of 6.8GB (in my case).

Ref: http://support.crashplan.com/doku.php/recipe/stop_and_start_engine

Posted in linux | Tagged , , , , | Leave a comment

Protected: DNS Tunnelling over Public Wifi

This content is password protected. To view it please enter your password below:

Posted in Uncategorized | Enter your password to view comments.

Individual IP routing in CentOS/KVM/Libvirt with Port Security

Note: if all your IPs are in the same subnet, you’d be better off using the instructions in this post.

Introduction

Generally when hosting VMs on publically accessible IPs, we create a network bridge and add the host’s network interface and all guest interfaces to that bridge. This is efficient and works great, except in situations where out hosting provider has “port security” enabled on their switches. This limits each port on the switch to one MAC address (the port on the switch being the port which our network card is physically connected to by cable). In the default bridge setup, every virtual network card will create traffic with it’s own MAC address, which isn’t allowed by port security… usually traffic from these addresses will be silently ignored, or even worse, our entire switch port might be disconnected, preventing access to the host machine too.

There are two solutions, the one is a ‘proxy arp’ setup, where our host will masquerade all VM traffic using it’s own MAC address, but transparently modify traffic accordingly so all works intended. The second is a routed setup, where our host acts as another router between our VMs and our ISP. While these are essentially almost the same thing, the advantage of the latter approach is that we can still use DHCP to configure our clients (which is impossible with proxy_arp since we don’t know the VM’s actual MAC address on the host’s side of the bridge).

Previously, the only way I found for adding single IPs involved setting up a tunnel interface (e.g. tap0, etc) for each IP address.  Besides being quite cumbersome, it required a vast reduction in security measures, which made it less than ideal.  This new method, involves setting up a new bridge, but one that isn’t directly bridged to the ethernet card in the host, and having the VM appear as a router in between.  So, the switch still only deals with one MAC address, but we can still use DHCP, etc.

Note: everything below works, but I’m still working on scripts to better automate the process.  (June, 2012).

On the Host

Network Definition

1. Generate a UUID for the network

$ uuidgen 
0fdc9175-4800-4499-a320-9fadf87a5bd3

2) Create a MAC address for our the router interface. KVM MAC addresses should look like this 52:54:00:XX:XX:XX, where the XX are random hex digits. We can generate one like this:

$ echo 52:54:00:`openssl rand -hex 3 | sed 's/\(..\)/\1:/g; s/.$//'`
52:54:00:e0:50:66

3) Create routed.xml, replacing relevant fields with data you generated above:

<network>
  <name>routed</name>
  <uuid>0fdc9175-4800-4499-a320-9fadf87a5bd3</uuid>
  <forward mode='route'/>
  <bridge name='virbr1' dev="eth1" />
  <mac address='52:54:00:e0:50:66'/>
  <ip address='10.0.0.1' netmask='255.255.255.255'>
  </ip>
</network>

4) Activate:

$ virsh net-define routed.xml
$ virsh net-start routed
$ # start automatically in future
$ virsh net-autostart routed

5) Allow forwarding over the bridge in your firewall with either:

# Forward all packets over libvirt routed network
iptables -A FORWARD -i virbr1 -j ACCEPT
iptables -A FORWARD -o virbr1 -j ACCEPT

or, even safer (but more resource intensive), a rule for each IP:

# Forward traffic for hostname
iptables -A FORWARD -s X.X.X.X -j ACCEPT
iptables -A FORWARD -d X.X.X.X -j ACCEPT

Save the current ruleset to be loaded on boot:

service iptables save

Note:  If you “virsh net-destroy routed” after the above rules are in effect, you’ll need to apply them again after recreating the network with “virsh net-start routed”.

You can verify you ruleset like this:

[[Ignore this.  TODO, verify; libvirt incorrect iptables rules, correct them with script.  Write about libvirt hook inadequacies for net-start, create script to compensate]]

6)  Create start-up scripts:

# If they don't already exist
mkdir /etc/libvirt/hooks
touch /etc/libvirt/hooks/qemu
chmod a+x /etc/libvirt/hooks/qemu 

# Critical if /etc/libvirt/hooks/qemu didn't exist before
service libvirt restart

Edit /etc/libvirt/hooks/qemu to include the following:

#!/bin/sh

# Add individual IPs for our routed network to the routing table
#
# Since no hook exists for net-start, the best we can do is check if
# all the IPs are added everytime a VM is launched, without re-adding.
# When a net-destroy occurs, the routes will be autoamtically removed.
. `dirname $0`/routed-ips
if [ "$2" == "start" ]; then
    for IP in $ROUTED_IPS ; do
        if [ "`ip route list | grep $IP`" == "" ] ; then
             ip route add $IP via $ROUTED_GW dev $ROUTED_DEV
        fi
    done
fi
exit 0

And create /etc/libvirt/hooks/routed-ips with something like:

ROUTED_GW="10.0.0.1"
ROUTED_DEV="virbr1"
ROUTED_IPS="X.X.X.X Y.Y.Y.Y Z.Z.Z.Z"

Guest definition files

In your VMs definition xml file, have the network section look similar to this:

<interface type='network'>
      <mac address='00:16:36:7b:4e:64'/>
      <source network='routed'/>
      <forward mode='route'/>
      <model type='virtio'/>
</interface>

On the Guest

Assumes eth1 is main network device.

Example /etc/sysconfig/network-scripts/ifcfg-eth1:

DEVICE="eth1"
NM_CONTROLLED="no"
ONBOOT=yes
HWADDR=52:54:00:b7:3c:c2
TYPE=Ethernet
BOOTPROTO="static"
IPADDR="X.X.X.X"
NETMASK="255.255.255.255"
DNS1="Y.Y.Y.Y"
DNS2="Z.Z.Z.Z"
# GATEWAY=  not needed, defined below

Most importantly, create /etc/sysconfig/network-scripts/route-eth1:

10.0.0.1 dev eth1
default via 10.0.0.1 dev eth1

 That’s it!

Let me know if you have any problems, comments on the method, etc.

Posted in kvm, linux, networking | Tagged , , , , | 7 Comments

Open mailto: links in Thunderbird on Linux (incl Chrome)

Didn’t expect this one to result in a blog post, but seeing as it took me more than 10 minutes to figure this out, figured the info might help others 🙂

This solution is probably only relevant if you installed Thunderbird under your home directory yourself, and not through your distributions packaging manager.

Chrome uses xdg-email to open mailto: links, which respects the open desktop standard.  Manually setingt this up so it works right with a home installation is actually quite simple, if you know what to do.

Step 1:

Create ~/.local/share/applications/thunderbird.desktop with the following contents, be sure to change the line in bold to change the location of your thunderbird binary (can be just “thunderbird” if it’s in your path…).

[Desktop Entry]
Encoding=UTF-8
Exec=/home/USERNAME/thunderbird/thunderbird
Icon=/usr/share/pixmaps/thunderbird.png
Type=Application
Categories=Application;Network;
Name=Thunderbird
Name[bn]=থাণ্ডারবার্ড
Name[eo]=Mozilo Tondrobirdo
Name[fi]=Mozilla Thunderbird
Name[pa]=ਥੰਡਰਬਰਡ
Name[tg]=Паррандаи бало
GenericName=Mail Client
GenericName[af]=Pos Kliënt
GenericName[ar]=البريد الألكتروني
GenericName[az]=Poçt Alıcısı
GenericName[be]=Паштовы кліент
GenericName[bg]=Пощенски клиент
GenericName[bn]=ইমেইল ক্লায়েন্ট
GenericName[br]=Arval postel
GenericName[bs]=Program za čitanje elektronske pošte
GenericName[ca]=Client de correu electrònic
GenericName[cs]=Klient pro čtení elektronické pošty
GenericName[cy]=Dibynnydd Ebost
GenericName[da]=E-mail-klient
GenericName[de]=E-Mail-Programm
GenericName[el]=Πελάτης mail
GenericName[eo]=Legi kaj sendi retpoŝton
GenericName[es]=Cliente de correo electrónico
GenericName[et]=Meiliklient
GenericName[eu]=Posta bezeroa
GenericName[fa]=کارگیر پست الکترونیکی
GenericName[fi]=Sähköpostiohjelma
GenericName[fo]=Postforrit
GenericName[fr]=Logiciel de messagerie électronique
GenericName[ga]=Cliant Ríomhphoist
GenericName[gl]=Cliente de correo
GenericName[he]=תוכנית דואר
GenericName[hi]=डाकिया
GenericName[hr]=Program za čitanje elektronske pošte
GenericName[hu]=Levelezőprogram
GenericName[id]=Klien Mail
GenericName[is]=Póstforrit
GenericName[it]=Programma di posta elettronica
GenericName[ja]=メールクライアント
GenericName[ko]=편지를 주고 받는 프로그램
GenericName[lo]=ໄຄແເອັນຈົດຫມາຍເອເລັກໂຕນິກ
GenericName[lt]=Pašto klientas
GenericName[lv]=Pasta Klients
GenericName[mk]=Програма за електронска пошта
GenericName[mn]=Э-Захиа-Програм
GenericName[mt]=Klijent tal-imejl
GenericName[nb]=E-postklient
GenericName[nds]=Mailprogramm
GenericName[nl]=E-mailclient
GenericName[nn]=Lesing og sending av e-post
GenericName[nso]=Moreki wa Poso
GenericName[oc]=Programari de correu electrònic
GenericName[pa]=ਪੱਤਰ ਕਲਾਂਇਟ
GenericName[pl]=Program do wysyłania i odbierania poczty elektronicznej
GenericName[pt]=Client de E-mail
GenericName[pt_BR]=Cliente de E-mail
GenericName[ro]=Program de poştă electronică
GenericName[ru]=Клиент электронной почты
GenericName[se]=Boastaprográmma
GenericName[sk]=Klient elektronickej pošty
GenericName[sl]=Program za e-pošto
GenericName[sr]=Програм за e-пошту
GenericName[sr@Latn]=Program za e-poštu
GenericName[ss]=Likhasimende leliposi
GenericName[sv]=E-postklient
GenericName[ta]=அஞ்சல் உறுப்பினர்
GenericName[tg]=Коргири почтаи эллектроникӣ
GenericName[th]=ไคลเอนต์จดหมายอิเล็กทรอนิกส์
GenericName[tr]=Posta İstemcisi
GenericName[uk]=Клієнт електронної пошти
GenericName[uz]=Хат-хабар клиенти
GenericName[ven]=Mushumisani na poso
GenericName[wa]=Cliyint d' emilaedje
GenericName[xh]=Umxhasi Weposi
GenericName[zh_CN]=邮件程序
GenericName[zh_TW]=郵件處理程式
GenericName[zu]=Umxhasi weposi
X-KDE-StartupNotify=true

Step 2:

Edit ~/.local/share/applications/mimeapps.list and add the following line under the [Added Assocations] section:

x-scheme-handler/mailto=thunderbird.desktop;

That’s it 🙂

 

Posted in linux | Tagged , , , | Leave a comment

E-Sky Simulator FMS in Linux / Windows

Note: The box says “MODEL1 002203” and “MODEL2 000502”, but I couldn’t find any way on the remote to identify which model it was.  It’s USB identifier is 0402:0402 ADC by ALi Corp.

E-Sky Simulator FMS in Linux / Windows (with FlightGear)

So I bought the ESKY HOBBY simulator pack, and the included CD contained just the freeware Flying-Model-Simulator package, which it seems was discontinued back in 2004. It doesn’t run on Windows 7, never mind Linux, fortunately there are some good open source alternatives.

Meet FlightGear, an open-source multi-platform flight simulator, with a host of features, including 3D support! And of course, create recognition for a variety of joysticks (in our case, a modified version of the E-SKY radio control built for it’s helicopters) — with some tweaking of course.

Installation Instructions

1. Download and install FlightGear

On Debian/Ubuntu: sudo apt-get install flightgear
Otherwise find the appropriate files from here:
http://www.flightgear.org/download/

2. Download appropriate aircrafts
The Alouette-III, Lynx-WG13 and S-51-Dragonfly are the most relevant helicopters.
3. Create $FG_HOME/Input/Joysticks/ADC.xml
Assuming you have the same controller as me.  If not, see [] about creating these files yourself.
The box says “MODEL1 002203” and “MODEL2 000502”, but I couldn’t find any way on the remote to identify which model it was.  It’s USB identifier is 0402:0402 ADC by ALi Corp.
<?xml version="1.0"?>
<PropertyList>
  <axis>
    <desc>Aileron</desc>
    <direction>right</direction>
    <binding>
      <command>property-scale</command>
      <property>/controls/flight/aileron</property>
      <offset type="double">0</offset>
      <factor type="double">-1</factor>
      <power type="int">1</power>
    </binding>
    <dead-band type="double">0</dead-band>
  </axis>
  <axis n="1">
    <desc>Elevator</desc>
    <direction>down/forward</direction>
    <binding>
      <command>property-scale</command>
      <property>/controls/flight/elevator</property>
      <factor type="double">1</factor>
      <power type="int">1</power>
    </binding>
    <dead-band type="double">0</dead-band>
  </axis>
  <axis n="4">
    <desc>Rudder</desc>
    <direction>right</direction>
    <binding>
      <command>property-scale</command>
      <property>/controls/flight/rudder</property>
      <factor type="double">-1</factor>
      <power type="int">1</power>
    </binding>
    <dead-band type="double">0</dead-band>
  </axis>
  <axis n="2">
    <desc>Throttle</desc>
    <direction>forward</direction>
    <binding>
      <command>nasal</command>
      <script>controls.throttleAxis()</script>
      <factor type="double">1</factor>
    </binding>
    <dead-band type="double">0.01031526178</dead-band>
  </axis>
 <name type="string">ADC</name>
</PropertyList>
4. Launch like this:
fgfs --aircraft=Alouette-III --timeofday=noon --enable-fullscreen --airport=LLHZ

Other cool stuff

3D view (with glasses), etc.
Posted in linux | Tagged , , , , , | Leave a comment

Routed (non-bridged) setup for KVM & libvirt (avoids port security) – Method 2: Routed subnet

Note: if you’re working with multiple individual IPs each in their own subnet, you’re better off referring to this post.

Introduction

Generally when hosting VMs on publically accessible IPs, we create a network bridge and add the host’s network interface and all guest interfaces to that bridge. This is efficient and works great, except in situations where out hosting provider has “port security” enabled on their switches. This limits each port on the switch to one MAC address (the port on the switch being the port which our network card is physically connected to by cable). In the default bridge setup, every virtual network card will create traffic with it’s own MAC address, which isn’t allowed by port security… usually traffic from these addresses will be silently ignored, or even worse, our entire switch port might be disconnected, preventing access to the host machine too.

There are two solutions, the one is a ‘proxy arp’ setup, where our host will masquerade all VM traffic using it’s own MAC address, but transparently modify traffic accordingly so all works intended. The second is a routed setup, where our host acts as another router between our VMs and our ISP. While these are essentially almost the same thing, the advantage of the latter approach is that we can still use DHCP to configure our clients (which is impossible with proxy_arp since we don’t know the VM’s actual MAC address on the host’s side of the bridge).

Note: this article discusses how to set up a block of IP addresses. If you’re being allocated individual non-contiguous IP addresses, unfortunately with libvirt+KVM the only solution involves a number of security sacrifices, which aren’t discussed here.  (Update:  this is now possible, see this post for details.) However, even if you aren’t assigned a big block, but have many IPs in the same subnet, you can still “cheat” and use the setup described below, as long as you’ll never need to access any IPs in that subnet that aren’t assigned to you (since all attempts to access those addresses will be routed to your VMs – although you could correct your hosts routing table as required).  So, not ideal, but it works.

Creating the Routed Network

Ref: Network type info from libvirt.org

Prerequisites

1) Generate a UUID for our network

$ uuidgen 
0fdc9175-4800-4499-a320-9fadf87a5bd3

2) Create a MAC address for our the router interface. KVM MAC addresses should look like this 52:54:00:XX:XX:XX, where the XX are random hex digits. We can generate one like this:

$ echo 52:54:00:`openssl rand -hex 3 | sed 's/\(..\)/\1:/g; s/.$//'`
52:54:00:e0:50:66

3) Our last prerequisite is an IP address for the bridge. If you’ve been assigned a real CIDR block, use the correct router address for that block. Otherwise, it’s possible to “cheat” and use any IP in the subnet, even if you don’t own it, since it will never be used outside of your system. (See the note about cheating above.)

Network Setup

Create a file ‘routed.xml’ similar to the below, but with the information you generated/chose above. In our example we’ll use the 192.168.123.0 network, but obviously this works fine with public IPs.

<network>
  <name>routed</name>
  <uuid>0fdc9175-4800-4499-a320-9fadf87a5bd3</uuid>
  <forward mode='route'/>
  <bridge name='virbr1' dev="eth1" />
  <mac address='52:54:00:e0:50:66'/>
  <ip address='192.168.123.1' netmask='255.255.255.0'>
    <dhcp>
      <host ip='192.168.123.2' name='static-ip.domain.net' mac='xx:xx:xx:xx:xx:xx' />
      <range start='192.168.123.2' end='192.168.123.254' />
    </dhcp>
  </ip>
</network>

Activate

$ virsh net-define routed.xml
$ virsh net-start routed
$ # start automatically in future
$ virsh net-autostart routed

VM setup

In your VMs definition xml file, have the network section look similar to the following.

<interface type='network'>
      <mac address='00:16:36:7b:4e:64'/>
      <source network='routed'/>
      <forward mode='route'/>
      <model type='virtio'/>
</interface>

You’ll find this setup works great with port security and dhcp too. Any questions, ask in comments below.

Posted in kvm, linux, networking | Tagged , , , , , | 5 Comments

Better LVM (Logical Volume Management) for KVM guests

Foreword: This post is aimed at advanced users and expects you to already understand LVM and virtualization (although all commands needed are shown).

Summary: What follows is an explanation of how, and why, you should do what I call hybrid LVM partitioning for your virtual machines, where each logical volume on the host is an entire file system on the guest, with the exception of a tiny logical volume which will appear as the boot drive, and have just a boot petition on it. This offers numerous advantages, as explained below.

Rationale:

I started off with virtualization on Xen; there it was standard practice to have every partition in the guest tied to a logical volume in the host. Like this:

Host                     Guest
---------------------    ---------
/dev/vg0/gandalf-boot    /dev/xvda1
/dev/vg0/gandalf-root    /dev/xvda2
/dev/vg0/gandalf-swap    /dev/xvda3

This is incredibly efficient and convenient for many reasons, not the least being easy backups and maintenance of those file systems from the host. But maintenance doesn’t just mean mounting, it means it’s incredibly easy to resize the partitions too, which is a common requirement when hosting many VMs.

In KVM, the standard practice is to have each logical volume on the host be an entire virtual disk in the guest, and have that partitioned appropriately. That means whereas before, a single logical volume would contain a single, easy to maintain file system, you’d now have a set up like this:

/dev/vg0/gandalf-disk
+
+-- partition table
    +
    +-- boot partition
        +
        +-- LVM partition
            +
            +-- swap partition
            +-- root partition

Currently, everyone seems to argue that this really isn’t such a big deal, since we can just use kpartx to map out these partitions on the host, and is at most just a few extra steps. And yes, that doesn’t seem so bad in the beginning. Until it comes time to resize the partitions, and then all hell breaks loose.

Look again at the diagram above, and think what’s involved in resizing all those file systems, logical volumes, partitions, and containing logical volume. Fortunately libvirt offers a tool called virt-resize which can automate a lot of this process, but owing to the inherent shortcomings of the above technique, you require twice again as much space as that first LVM partition… because essentially what the script does is create a new LVM partition, with a new partition table, and copies all the data across for you. While a lot more convenient for the user than doing all the insane steps by hand, this is still very inefficient, slow and simply unnecessary.

KVM virtual machines are generally set up this way because KVM guests aren’t paravirtualized, and the system needs a full (albeit virtual) hard drive to boot off, just like in a real system. But many seem to have overlooked the fact that while this is required for booting, other “drives” can easily host a full file system without the need to be partitioned first.

This leads us to what I call hybrid LVM partitioning. It may be a bit hard to understand just from the name what’s involved there, but basically, we have one *small* logical volume appear as an entire disk, with boot sector, partition table, and single small boot partition. All other partitions will be as described in the first setup, where each logical volume on the host is a device with just a full file system on it.

This let’s us boot in KVM, while still giving us all the convenience and other advantages of the set up we first described. And this is fine too, since we’ll most likely never need to resize the boot partition, and if we do, there really isn’t so much work involved. Everything else, we can resize as we’d normally expect for a logical volume. So now we have this:

Host                     Guest
---------------------    ---------
/dev/vg0/gandalf-boot    /dev/vda
                         + partition table
                         + + boot partition ( /dev/vda1 )
/dev/vg0/gandalf-root    /dev/xvda2
/dev/vg0/gandalf-swap    /dev/xvda3

Here’s an example of how to create that first device on volume group vg0:

# lvcreate -n gandalf-boot -L 256M /dev/vg0
# fdisk /dev/vg0/gandalf-boot << __END__
n
p
1

a
1
w
__END__
# kpartx -a /dev/vg0/gandalf-boot
# mkfs.ext2 /dev/mapper/vg0-gandalf--boot1 # 1st partition
# # possibly mount device, copy files, unmount, if desired
# kpartx -d /dev/vg0/gandalf-boot

What we just did: 1) Create the logical volume, 2) in fdisk: create a new primary partition 1, filling the full disk, make it bootable, write, and 3) map the drive and create the ext2 file system), unmap the drive. As for the other partitions, something like this:

# lvcreate -n gandalf-root -L 8G /dev/vg0
# mkfs.ext4 /dev/vg0/gandalf-root
# lvcreate -n gandalf-swap -L 2G /dev/vg0
# mkswap /dev/vg0/gandalf-swap

In your libvirt guest xml file, define the disks like this

<disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source dev='/dev/vg0/gandalf-boot'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source dev='/dev/vg0/gandalf-root'/>
      <target dev='vdb' bus='virtio'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source dev='/dev/vg0/gandalf-swap'/>
      <target dev='vdc' bus='virtio'/>
</disk>
In your guest, the assignments will be as per the diagram above (gandalf-boot = vda, with the boot partition on vda1, gandalf-root = vdb, gandalf-swap = vdc) -- however, you'll probably want to use UUIDs or LABELs to find them in the guest (beyond the scope of this blog entry).

Good luck!

See also:

Posted in kvm, linux | Tagged , , , , , , | 2 Comments

Useful sysrecuecd chroot stuff [WIP]

mkdir /mnt/tmp
mount /dev/vdb /mnt/tmp
mount /dev/vda1 /mnt/tmp/boot
mount -o bind /proc /mnt/tmp/proc
mount -o bind /dev /mnt/tmp/dev
mount -o bind /dev/pts /mnt/tmp/dev/pts
mount -o bind /dev/sys /mnt/tmp/sys/
chroot /mnt/tmp /bin/bash

Refs:
* http://www.sysresccd.org/forums/viewtopic.php?t=1684

On Debian/Ubuntu:

dpkg-divert –local –rename –add /sbin/initctl
ln -s /bin/true /sbin/initctl

Refs
* http://mrzard.posterous.com/failed-to-connect-to-socket-comubuntuupstart

Posted in linux | Tagged , , , | Leave a comment

Routed (non-bridged) setup for KVM & libvirt (avoids port security) – Method 1: proxy_arp

Note: this method has been largely superseded by the one described in this post. The advantage of the newer method is easier setup and working DHCP.

Original Post

The default set up for virtual machines involving setting up a bridge, and having the virtual machine NICs appear on the same network as the host. This can be problematic if your hosting provider has port security enabled on their switches… the minute they detect more than one MAC address coming from your LAN port, they will either reject the packets from the new MACs, or disconnect you all together.

The way around this is to use a proxy arp, thereby having your host use it’s own MAC address when talking to the switch, but transparently forward packets in both directions with the correct MAC information. So, the switch sees only your host’s MAC address, and all your VMs operate as usual with their own MAC addresses. Everyone’s happy.

In my case I’m running CentOS release 6.2, and some of these instructions will be CentOS/RHEL/Fedora specific. Adapt as necessary for Debian-based or other Linux distributions.

Install the necessary tools (most likely already installed standard):

yum install iproute bridge-utils

Create /etc/sysconfig/network-scripts/ifcfg-br0, and change the relevant addresses and masks as required. The IPADDR X.X.X.X below is the IP address you’re going to assign your bridge. It’s only used internally and does not need to be a public IP. By convention, you’ll make it very similar to your hosts public IP, but with 254 as the last octet. So, if your IP was 192.168.0.20, you’d change the X.X.X.X below to 192.168.0.254.

DEVICE="br0"
TYPE="Bridge"
BOOTPROTO="static"
IPADDR="X.X.X.254"
NETWORK="X.X.X.X.0"
NETMASK="255.255.255.0"
ONBOOT="yes"
#NM_CONTROLLED="no"

Edit /etc/sysctl.conf:

Near the top, make sure “net.ipv4.ip_forward = 1” is set (the default value is 0; if the line doesn’t exist at all, add it). Directly underneath, or add the end of the file, add the line:

# br0 proxy_arp (make sure net.ipv4.ip_forward=1, above)
net.ipv4.conf.br0.proxy_arp = 1

The changes will take effect from your next reboot. To avoid the need to reboot, you can activate them for the first time with:

ifup br0
sysctl -w net.ipv4.conf.br0.proxy_arp=1
sysctl -w net.ipv4.ip_forward=1

Now, continue to deploy your VMs on br0 as usual. libvirt will take care of creating the appropriate network devices and adding them to the bridge. You can confirm this with ‘brctl show br0’ after launching a VM.

Inside the VM, set the GATEWAY address to be the IP address you gave your bridge, above, e.g. 192.168.0.254.

Note: This post was largely based off the following (intended for Debian-based systems) — http://riaschissl.blogspot.com/2009/06/port-security-proxying-kvm-mac.html

Posted in kvm, linux, networking | Tagged , , , , , , | 1 Comment

Support for Spotify URLs in Linux

Spotify makes it easy to share playlists between users. And websites like www.spotifylist.com help you find playlists from people you don’t know.

By default, the Linux version of Spotify doesn’t add the necessary url-handlers to let you simply click on Spotify URLs on the internet and launch them automatically.

Modern distributions will send urls to xdg-open which on a GNOME desktop, in turn, uses gnome-open to try and launch the correct default application.

Typing the following lines in a terminal will make sure you’re good to go.

gconftool-2 -t string -s /desktop/gnome/url-handlers/spotify/command 'spotify -uri "%s"'
gconftool-2 -s /desktop/gnome/url-handlers/spotify/enabled true -t bool
gconftool-2 -s /desktop/gnome/url-handlers/spotify/needs_terminal false -t bool

You can confirm that these have been set correctly in gconf-editor.

And you can test the set up from the terminal like this:

gnome-open "spotify:user:sharpblue:playlist:33FQ0bK3GVtRC98WsB8hE4"

Good luck!

Alternative Solution

Found on ubuntuforums.org here (from user fresta):

Create (as root) a file “/usr/share/applications/spotify-uri.desktop” (or as a user “~/.local/share/applications/spotify-uri.desktop”) with:

[Desktop Entry]
 Name=Spotify
 GenericName=Spotify
 Comment=Listen to music using Spotify
 Icon=spotify-linux-512x512
 TryExec=spotify
 Exec=spotify -uri %u
 Terminal=false
 Type=Application
 Categories=Qt;AudioVideo
 MimeType=x-scheme-handler/spotify
 NoDisplay=true

And then run:

sudo update-desktop-database

This has worked for people who had no luck with the gconf keys method, and should work on non-GNOME desktops too.

Posted in gnome, linux, spotify | Leave a comment