© boing, photocase.com

Wenn sie die Desktops verteilter Benutzer auf einem Server zentral virtualisieren sollte, war Virtualbox bislang nicht gerade als Heldin ausgeklügelter Authentifizierungsmechanismen bekannt. Das nagelneue Projekt Vrdp-ldap behebt das Manko in allen LDAP-Umgebungen.

Die eigentlich auf Linux-, Windows-, Free-BSD- und Solaris-Desktop-PCs von Endusern abonnierte Virtualisierungssoftware Virtualbox [1] macht sich auch für den Einsatz auf Servern hübsch. Mit der Version 3.1 hatte der damalige Eigner Sun unter der Bezeichnung “Teleportation” eine Live-Migration der virtuellen Maschinen eingeführt.

Seit Sun unter den Schwingen von Oracle untergekommen ist und seit Version 3.2 virtualisiert “Oracle VM Virtualbox” auch MacOS X auf Non-Apple-Hardware (siehe Kasten “Mac OS ohne Mac”). Sie kennt konfigurierbares I/O-Caching und NAT, CPU-Hotplugging, RDP-Video-Beschleunigung (leider nur mit Windows-7-RDP-Clients) und mehrere Monitore.

Das von Terminalservern bekannte Protokoll RDP gibt Oracle jedoch nur der Bezahlversion von Virtualbox mit auf den Weg. Die “Personal Use and Evaluation License” (PUEL, [2]) gestattet zum Glück Privatanwendern und Bildungseinrichtungen, die proprietäre Version lizenzkostenfrei zu benutzen. Das eröffnet dieser Gruppe die Möglichkeit, den folgenden Artikel praktisch umzusetzen.

Mac OS ohne Mac

Seit Virtualbox 3.2 kann die Virtualisierung auch Apples Betriebsystem unter Linux auf beliebiger Hardware in einem Fenster laufen lassen (Abbildung 1). Möglich macht das, wie auch bei KVM (Abbildung 2), die Emulation der Bootumgebung EFI (Extensible Firmware Interface). Abbildung 1: In manchen Ländern verboten: Mac OS X auf einem Intel-Laptop mit Virtualbox. Abbildung 2: Auch KVM kann mithalten, hier eine ältere Version von Apples Betriebssystem. Vorsicht: Apples Nutzungsbedingungen verbieten es dem Käufer, Mac OS auf anderer als der Apple-Hardware zu verwenden, obwohl Steve Jobs’ Company in seinen Shops OS X auch ohne Hardware verkauft. Ob das Verbot allerdings in Deutschland Bestand vor Gericht hätte, ist unter Experten strittig. Virtualbox gestaltet Virtualisieren des Apfels einfach: Der Admin erstellt eine neue VM, wählt »Mac OS Server« aus und definiert einen Festplattencontroller vom Typ »ICH6«. Damit der Leopard bootet, braucht es noch den richtigen »VBoxManage«-Befehl (mit dem SMC-Device-Key aus dem Internet). Flüssig läuft es aber erst, wenn der User Apples Powermanagementfunktionen deaktiviert.

LDAP kanns richten

Als Stolperstein gilt das Authentifizieren per VRDP an einer laufenden virtuelle Maschine. Den vorgesehenen Weg per PAM führt nur genau den Benutzer auf einem bestimmten Host zum Ziel, der ursprünglich die virtuelle Maschine auf dem Virtualbox-Server gestartet hatte. Wechselt der Benutzer an einen anderen RDP-Clientrechner, geht die PAM-Authentifizierung schief. Admins, die ihre User von den Hosts entkoppelten, müssen PAM abschalten und versuchen per Firewall den Zugriff zum VRDP-Port zu begrenzen.

Da dies jedoch in der Praxis kaum effizient zu handhaben ist, enstand im Juni dienen Jahres das Projekt Vrdp-ldap [3], das für Virtualbox ein Authentifikationsmodul gegen LDAP-Server implementiert. Es erweitert ein vorhandenes LDAP-Schema um eine Objektklasse und ein Attribut, was die benutzerorientierte Authentifizierung über eine so genannte Machine UUID ermöglicht. Da Vrdp-ldap die vorhandenen Verzeichnisattribute von PAM mit nutzt, ist die Authentifikation transparent auf bestehende Verzeichnisdienste mit vorhandenen Anmelde-Credentials der Benutzer abbildbar.

Für Open Suse 11.2 und SLES 11 hält [4] installationsfertige RPM-Pakete bereit. Admins anderer Zielsystemen übersetzen die Quellen wie üblich mit »configure && make && make install«. Das manuelle Übersetzen erfordert die Gegenwart der Entwicklerpakete »libHX«, »pam-devel«, »openldap2-devel« sowie »pkg-config«, die gängige Distributionen vorhalten.

Schritt für Schritt

Das Einrichten einer virtuellen Maschine mit LDAP-basierter VRDP-Authentifikation passiert in fünf Schritten auf dem Virtualbox-Hostsystem:

1. Installation des VRDP-LDAP-Plugins,

2. Einstellung der VRDP-Bibliothek für Virtualbox,

3. Anpassen des LDAP-Schemas,

4. Anpassen der virtuellen Maschine selbst und

5. Erweitern der LDAP-Benutzeraccounts um die UUID(s) der virtuellen Maschine(n), auf die der Benutzer zugreifen soll.

Auf einem Open Suse 11.2 ist die Installation des Plugins schnell gemacht:

zypper ar http://repo.medozas.de/medozas/SUSE-11.2/medozas.repo
zypper in VirtualBox-vrdp-ldap

Nun zur VRDP-Bibliothek: Passend zu eigenen Virtualbox-SDK-Version (3.0 bis zur aktuellen 3.2.4) muss der Admin das kompilierte Modul mittels »VBoxManage« als VRDP-Library deklarieren. Für 32-Bit-Systeme lautet das Kommando:

VBoxManage setproperty vrdpauthlibrary /usr/lib/virtualbox/vrdp-ldap

Auf 64-Bit-Systemen muss Root folgendes in die Shell tippen:

VBoxManage setproperty vrdpauthlibrary /usr/lib64/virtualbox/vrdp-ldap

Beim Namen des Moduls entfallen Dateiendungen wie ».so« oder ».dll«. Dies ist eine gute Idee, da es die VRDP-Authentifikation host- und betriebssystemübergreifend mit der identischen Einstellung wahrt. Zwar existiert zu Vrdp-ldap noch kein Windows-Modul, es ist jedoch eines in den nächsten Monaten zu erwarten.

Listing 1 zeigt Konfigurationsdatei zu Vrdp-ldap, die der Admin gegebenenfalls zum LDAP-Server passend machen muss. Den LDAP-Server erweitert er jetzt um das Schema »/usr/share/doc/packages/VirtualBox-vrdp-ldap/vbox-vrdp.schema«. Der vierte Schritt, das Anpassen der virtuellen Maschine(n) selbst, ist anhand des Screenshots in Abbildung 3 einfach machbar.

Abbildung 3: Nach dem Setup von Vrdp-ldap lässt sich jede einzelne virtuelle Maschine so konfigurieren, dass Virtualbox VRDP-Clients per LDAP authentifiziert.

01 CHECK_UUID="yes"
02 CHECK_PAM="yes"
03 PAM_SERVICE="sshd"
04 LDAP_URI="ldap://localhost/"
05 BASE_DN="dc=company,dc=com"
06 #BIND_DN=""
07 #BIND_PW=""

Pro Benutzer ein Eintrag

Zurück auf dem Wirtssystem: Zum letzten Schritt liefert das Listing 2 eine Blaupause. Zu sehen ist ein Standard-Benutzer im LDAP, der VRDP-Zugriff auf zwei virtuellen Instanzen eingeräumt bekommt. Pro Benutzer und Gast bedarf es eines eigenen LDAP-Eintrags. Die Entwickler denken über die Unterstützung des Wildcard »*« nach, der einem Benutzer Zugang zur jeden virtuellen Maschine zu ermöglichen würde. Mit welchem LDAP-Tool man den User anlegt, ist Geschmckssache, solang es das Schema abfragen kann, also das verfügbare »VBoxVRDP« als Objektklasse und »VBoxVRDPUUID« als Attribut. GQ [5] oder LDAP Admin [6] beispielsweise eignen sich gut.

Der in Listing 2 angegebene »VBoxVRDPUUID« stellt die Machine UUID der virtuellen Maschine selbst dar. Schade ist, dass die Maschinen-UUID lediglich in den XML-Dateien der jeweiligen VM selbst oder per »VBoxManage list« zu finden ist und nicht der GUI zu entnehmen. Ein Feature-Request zur Einsicht der UUID in der Virtualbox-Oberfläche ist bereits gemeldet [7].

01 dn: uid=mkromer,ou=users,dc=linux-magazin,dc=de
02 cn: mkromer
03 uid: mkromer
04 mail: medozas@medozas.de
05 objectClass: top
06 objectClass: person
07 objectClass: inetOrgPerson
08 objectClass: posixAccount
09 objectClass: VBoxVRDP
10 VBoxVRDPUUID: {3f7d197f-072a-4bf9-9528-aebefdfa2a2e}
11 VBoxVRDPUUID: {af4bed3e-f94e-48f8-ba1e-6c7c504b38ca}

Schlaues Initskript

Nun sind LDAP und Virtualbox ein Virtualisierungsgespann, und die Benutzer können per Rdesktop oder jedem anderen RDP-Terminalclient die Verbindung mit den Anmelde-Credentials aufbauen:

rdesktop -u LDAP-Benutzer -p Passwort_oder_'-'_für_Aufforderung VirtualBox-Host-IP:VRDP-Port

Mit diesem Rüstzeug lässt es sich an den Selbstbau eines Virtualbox-Servers mit Vrdp-ldap gehen. Zu empfehlen ist diesen mit einem speziellen Initskript [8] auszustatten. Es friert alle in der Autostart-Datei definierten virtuellen Maschinen im ihrem aktuellen Status ein, wenn der Host herunterfährt (»VBoxManage controlvm savestate«). Nach einem Neustart stehen die Gastsysteme ihren Benutzern sofort wieder zur Verfügung.

Voraussetzung hierfür ist, dass sich an der Konfiguration der virtuellen Maschine selbst (Netzwerk-Interfaces et cetera) seit dem Boot des Hostsystems nichts geändert hat. Zum Einrichten des Initskripts muss der Admin einen Benutzer anlegen, welcher der Gruppe »vboxusers« beitritt. Außerdem hat der Admin die Namen der definierten virtuellen Maschine mit VRDP-Port-Nummer und Prozesspriorität (Nice-Value) in der Autostart-Datei zu hinterlegen. Das Listing 3 zeigt die nötigen Kommandos für Open Suse.

01 useradd -c "VirtualBox User" -d /virt -m -r -g vboxusers virt
02 wget http://dev.medozas.de/files/VirtualBox/virtualbox.init.suse -O /etc/init.d/virtualbox
03 chmod a+x /etc/init.d/virtualbox
04 wget http://dev.medozas.de/files/VirtualBox/virtualbox.autostart.suse -O /virt/autostart
05 insserv virtualbox on

Offenbar ansteckend

Momentan wirft Oracle etwa im Monatsrhythmus eine neue Virtualbox-Version in die Softwarewelt. Angesichts der seit Version 3.1 hinzugekommenen Features und ermutigenden IO-Tests [9] lässt sich hochrechnen, dass Oracle einen Hybriden zwischen Desktop- und Servervirtualisierung heranzüchten will, der die Lasten eines 24/7-Produktivbetrieb schultert.

Ein paar Problemchen sind bis dahin noch zu beheben, beispielsweise mit dem USB-Treiber für Blackberrys oder mit der Interruptverarbeitung bei Mehrprozessorsystemen (die IO-APIC-Kommunikation mancher Gäste setzt den Host unter Volllast [10]). Das ändert aber nichts an der Richtigkeit des Weges von Virtualbox. Das hier vorgestellte nagelneue Türregime für LDAP-Umgebungen ist ein Indiz dafür, dass freie Projekte sich von Virtualbox’ Tempo anstecken lassen. (jk)