Some time ago a Kernel change broke a qemu-kvm feature known as ifup script.

I came across this while i was installing convirt (a nice web management tool for not only kvm). New VMs with bridged ethernet just wouldnt start and spit out an error like:

could not configure /dev/net/tun (tap%d): Operation not permitted

A few google searches later i tried the suggestion over linux capabilities (libcap2), but that did not worked for me. Also running the VMs as root was not an option!

Luckily, /usr/sbin/kvm is just a symlink on gentoo, so i made a little wrapper-script for creating the tap interfaces on demand!

Be aware that your ifup-script might be called different, if youre not using convirt! I also had to set the suid bit on brctl as well as tunctl!

#!/bin/bash

setup_tap()
{
NEWTAP=`tunctl -u convirt | cut -d “‘” -f 2`
/sbin/brctl addif br0 $NEWTAP
}

for PARAM in $@; do
if `echo $PARAM | grep -q “qemu-ifup-br0″ `; then
setup_tap
NEWPARAM=`echo $PARAM | sed ‘s//etc/kvm/qemu-ifup-br0/no,ifname=’$NEWTAP’/g’`
PARAMSTRING=”$PARAMSTRING
$NEWPARAM”
else
PARAMSTRING=”$PARAMSTRING $PARAM”
fi
done

/usr/bin/qemu-kvm $PARAMSTRING

Wer kennt das nicht: Ein in die Jahre gekommener Server sollte abgelöst oder abgeschaltet werden, jedoch weiss man nicht genau, ob noch jemand auf die betriebenen Serverdienste zugreifft oder nicht.
Natürlich kann man anhand der Logs versuchen herauszufinden obs überhaupt noch genutzt wird und allenfalls auch von wem und woher… Doch nicht immer sind diese Infos auch wirklich hilfreich, da allenfalls über ein VPN verbunden wurde oder der gesuchte Rechner bereits wieder abgestellt wurde!
Wenn man jedoch weiss, was der Dienst genau macht und wie man diesen Clientseitig allenfalls auf einen neuen Server umstellt, dann steht einer automatischen Umstellung eigentlich nicht viel im Wege! 🙂

-Man nehme einen Linux-Server im gleichen Subnet wie der Alte Server.
-Man installiert sich xinetd
-Falls es sich um Windows-clients handelt, ist wohl auf das Tool winexec auf dem Server nicht zu verzichten.
-Man baut sich ein client-script, dass die gewünschten Änderungen auf dem Client-Rechner vornimmt.
-Man baut sich ein Server-script, dass das Client-script ausführt. (Hier kann man vorzugsweise via ssh connecten oder halt via winexec.) <-Xinetd füllt freundlicherweise die System-Variable $REMOTE_HOST mit der IP des zugreiffenden Clients!!
-Nun konfiguriert man xinetd…
Dazu in /etc/xinetd.conf die “only_from” zeile auf 0.0.0.0 ändern, damit Verbindungen von überall her angenommen werden. Für den eigentlichen Dienst habe ich einfach die rsh-config genommen und mir ein /etc/xinetd.d/madservice erstellt mit folgendem inhalt:

service madservice
{
socket_type     = stream
protocol        = tcp
wait            = no
user            = root
server          = /tmp/mad-service
log_on_success  = PID HOST USERID EXIT DURATION
log_on_failure  = USERID ATTEMPT
disable         = no
}

-Damit xinetd den Port kennt, auf den wir uns binden möchten, müssen wir diesen noch in /etc/services hinterlegen! (bspw: echo 12345 madservice >>/etc/services)
-Als nächstes zieht man dem alten Server den Stecker, bindet die ip als Alias auf dem Linux-Server (bspw: ifconfig eth0:0 192.168.1.99 netmask 255.255.255.0)
-Xinetd starten und geniessen! 🙂