Beim Sichern einer Datenbank mittels mysqldump hatte ich das Problem, dass immer irgendeine Fehlermeldung auftauchte, die auf das Fehlern irgendeiner Datei hinwies. Bei genauerer Recherche stellte ich fest, dass es sich um ein Problem mit der Zahl der offenen Dateien handelt. Mysqldump versucht anscheinen alle Tabellen parallel zu öffnen und diese Datenbank besitzt sehr viele Tabellen.

Eine Einfache Lösung besteht darin statt (hier als root):

mysqldump datenbank -p > /tmp/datenbank.sql

zu schreiben:

mysqldump datenbank --single-transaction -p > /tmp/datenbank.sql

Damit funktioniert der Dump dann auch. Siehe dazu auch http://rackerhacker.com/2007/08/19/mysql-errcode-24-when-using-lock-tables/

Nachdem Ghostery nun in meinem Firefox alle kommerziellen Webwanzen blockt habe ich begonnen selber mit Webwanzen zu experimentieren. Dafür gibt es das Programm Piwik, das man auf einem eigenen Server installieren und dann in die eigenen Seiten einbinden kann. Damit bekommt man ausführliche Hinweise über die Nutzung der Seiten, ohne Daten aus der Hand zu geben. Alles läuft auf eigenen Rechnern.

In die Webseiten, die ausgewertet werden sollen, muss man nur folgenden Code integrieren (und natürlich anpassen):

<!-- Piwik -->
 <script type="text/javascript">
 var pkBaseURL = (("https:" == document.location.protocol) ? "https://mein-server.de/piwik/" : "http://mein-server.de/piwik/");
 document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
 </script><script type="text/javascript">
 try {
 var piwikTracker = Piwik.getTracker(pkBaseURL + "piwik.php", 2);
 piwikTracker.trackPageView();
 piwikTracker.enableLinkTracking();
 } catch( err ) {}
 </script><noscript><p><img  src="http://mein-server.de/piwik/piwik.php?idsite=2" style="border:0"  alt="" /></p></noscript>
 <!-- End Piwik Tag -->

Für die Integration in Content Management Systeme findet sich unter http://piwik.org/faq/plugins/ eine Reihe von Plugins. Leider ist deren Nutzung nicht immer unproblematisch.

Für die Mediawiki-Integration findet sich unter http://www.mediawiki.org/wiki/Extension:Piwik_Integration eine passende Software. Man muss nur beim Download aufpassen. Hier wird man nach der benutzten Mediawiki-Version gefragt. Wählt man hier z.B. wahrheitsgemäß 1.15.x so bekommt man eine alte, bei mir nicht funktionsfähige Version. Man sollte hier als Mediawiki-Version unbedingt Development version (trunk) auswählen. Dann lädt man momentan die funktionsfähige Version Piwik-trunk-r72455.tar.gz .

Auch bei WordPress ist die Integration nicht unbedingt problemlos. Das Plugin Piwik Analytics ist über die Plugin-Verwaltung zu installieren und vermutlich auch funktionsfähig. Ich benutze aber momentan ein Template, bei dem in der Footer-Datei der Aufruf von wp_footer() fehlt. In diese Funktion klingt sich das Plugin wohl ein. Da in der footer.php zu meinem Template nur HTML-Code steht habe ich den Piwik-Code hier direkt eingebunden, damit funktioniert Piwik auch hier, zumindest solange ich das Template nicht wechsle.

Für Typo3 gibt es unter http://typo3.org/extensions/repository/view/piwik/current/ ebenfalls eine passend Extension. Diese muss ich noch ausprobieren. Bisher habe ich den Piwik-Code einfach mit in das Root-Template aufgenommen:

page.headerData.199 = TEXT
page.headerData.199.value (
 <!-- Piwik -->
 <script type="text/javascript">
 var pkBaseURL = (("https:" == document.location.protocol) ? "https://mein-server.de/piwik/" : "http://mein-server.de/piwik/");
 document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
 </script><script type="text/javascript">
 try {
 var piwikTracker = Piwik.getTracker(pkBaseURL + "piwik.php", 1);
 piwikTracker.trackPageView();
 piwikTracker.enableLinkTracking();
 } catch( err ) {}
 </script><noscript><p><img src="http://mein-server.de/piwik/piwik.php?idsite=1" style="border:0" alt="" /></p></noscript>
 <!-- End Piwik Tag -->
)

Damit erscheint der Code im Header-Bereich der Seite und nicht wie in der Anleitung beschrieben am Ende des Body-Bereiches, aber auch das funktioniert bisher.

Inzwischen habe ich auch die Extension piwiki aus dem Typo3-Repository ausprobiert und zwar in der Version 2.0.0. Die Extension muss nur installiert und aktiviert werden, dann folgen noch vier Zeilen im Root-Template:

config.tx_piwik {
  piwik_idsite = 1
  piwik_host   = http://mein-server.de/piwik/
}

Entgegen der Beschreibung muss hier wirklich http:// mit angegeben werden, sonst entstehen relative Verweise. Bevor man die Installation testen kann, muss man sich unbedingt vom Backend abmelden. Solange man im Backend angemeldet ist erfolgt nämlich keine Integration des Piwik-Codes.

Weitere Informationen zur Integration von Piwik in Typo3 finden sich bei Mittwald.

Heute hatte ich etwas Stress mit meinem Ubuntu-9.10 System.  Der Rechner wollte nicht booten und lieferte nach dem Boot-Menü die Fehlermeldung

Gave up waiting for root device. Common problems
- Boot args (cat /proc/cmd/line)
  - Check rootdelay= (did the system wait long enough?)
  - Check root= (did the system wait the right device?)
- Missing modules (cat /proc/modules;ls /dev)
Alert! /dev/disk/by-uuid/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx does not exist

Da sowohl bei Grub2, als auch in der fstab alle Partitionen per UUID angesprochen wurden ein ernsthaftes Problem. Als ich ein Testsystem von Ubuntu 10.04 gestartet habe war die Partition auch per UUID erreichbar und keine Fehler auf der Festplatte erkennbar.

Ich habe den Rechner dann mit einer Grub-Shell erfolgreich starten können mittels:

set root=(hd0,6)
linux  /vmlinuz  root=/dev/sda6
initrd  /initrd.img
boot

Das System startete auf diese Art. Es war dann aber wirklich die Partition sda6 nicht per UUID erreichbar.  In /dev/disk/by-uuid fehlte der Link auf die Partition und

blkid

lieferte Informationen über alle Partitionen außer sda6. Mittels

blkid -p /dev/sda6

kann man Informationen erzwingen, aber hier kam nur ein Hinweis auf verschiedene Partitionstypen.

ambivalent result (probably more filesystems on the device)

Es scheint sich hierbei um ein unglückliches Zusammenspiel mehrerer normalerweise unauffälliger Fehler zu handeln, zumindest unter 10.04 tritt das Problem so nicht auf. Eine Beschreibung habe ich dann unter http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg2057379.html gefunden.

Minix uses the "magic number" 137f, 138f, 2468,2478,  at  the location 0x410   to mark a Minix file system.
- 0x410 is also the location any ext filesystem uses to record the number of free inodes.
- (The number of free inodes is essentially the number of files you are still able to create on the file system)
+ 0x410 is also the location any ext filesystem uses to record the number
+ of free inodes.

  In  decimals  those four umbers are  4991,5007,9320,9336

  If the number of free inodes happens to  be one of those four numbers plus a multiple of 65536,
  then  the  ext filesystem will write  one of the four  Minix magic numbers  to the 0x410 location.

Bei einer unglücklichen Zahl von freien Inodes in der Partition lässt sich blkid irritieren und die Informationen z.B. über die ID werden nicht richtig gelesen.

Die Lösung ist im Prinzip einfach. Man muss nur einen einzigen zusätzlichen Inode belegen oder freigeben. Mein System hätte ich also nur rebooten müssen, ich hatte es ja zum Laufen gebracht und damit die Zahl der Inodes verändert.

Da unklar ist, wann dieses Problem mal wieder auftritt habe ich lieber von UUID auf Devices umgestellt. Dazu muss man einerseits die /etc/fstab umstellen, die notwendigen Informationen finden sich dort aber als Kommentare. Dann muss man die Grub2-Konfiguration umstellen.

Am Ende der Datei /etc/default/grub muss man ein Kommentarzeichen entfernen, damit GRUB_DISABLE_LINUX_UUID=true aktiv wird

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entrys
#GRUB_DISABLE_LINUX_RECOVERY="true"

Nun noch die Konfiguration neu erzeugen lassen mittels:

update-grub

und dann steht einem Reboot nichts mehr im Wege. Das Ändern der /etc/default/grub ist nicht mal unbedingt notwendig, da update-grub die Partition perr UUID nicht findet und dann von sich aus mit den Device-Bezeichnungen arbeitet.

Bei der Recherche zu diesem Problem habe ich zusätzlich gelernt, dass die UUID per tune2fs und per mkfs gesetzt werden kann.

Bei der Entwicklung von Webseiten muss man gelegentlich das Browserfenster exakt auf eine bestimmte Größe einstellen. Dabei hilft das Programm xdotool (ggf. Nachinstallieren). Die Nutzung erfolgt von der Textkonsole aus. Will man das Firefox-Fenster auf exakt 1024×768 Punkte einstellen so muss man zuerst an seine Nummer herankommen. Dies geschieht mittel:

xdotool search --onlyvisible --title "Mozilla Firefox"

Als Rückgabe erhält man eine oder ggf. mehrer Nummern von passenden Fenstern, z.B. 71802061 Mit dieser Nummer kann man das Fenster dann manipulieren:

xdotool windowsize 71802061 1023 768

nimmt die entsprechende Einstellung vor.  Das Fenster darf aber nicht im Vollbild sein, sondern muss schon etwas verkleinert sein.

Mit dem Programm xdotool kann man auch Eingaben in Fenster machen.

Sollte es mühsam sein die Fensternummer über den Titel zu ermitteln, so kann man auch das Programm xwinfo benutzen. Das fordert einen auf das gewünschte Fenster anzuklicken und gibt dann eine Reihen von Informationen aus, unter Window-Id die Nummer. Die Nummer ist hier hier hexadezimal angegeben, aber auch damit kann xdotool umgehen.

Auf meinem aktuellen Karmic-System wollte ich gern majordomo installieren. Primär eigentlich nur, um das Kommando approve absetzen zu können, mit dem ich bouncende Mails aus den von mir betreuten Mailinglisten bestätigen kann. Leider habe ich bisher kein Debian-Paket für mein Ubuntu finden können, vermutlich hat das mit Sicherheitsproblemen dieser etwas älteren Software zu tun.

Beim aktuellen OpenSuSe wird majordomo immer noch mit ausgeliefert. Daher war die Idee naheliegend das RPM-Paket mittels alien in ein Debian-Paket zu verwandeln und dann zu installieren. Leider war das nicht ganz so einfach. Das Ubuntu-Alien kommt teilweise mit aktuellen RPM-Paketen nicht zurecht, da die Art der Komprimierung verändert wurde. Das Problem scheint aber schon älter zu sein, es hat sich anscheinend aber noch niemand ernsthaft darum gekümmert. Es gibt Fehlermeldungen der Art:

Unpacking of 'majordomo-1.94.5-457.1.i586.rpm' failed at /usr/share/perl5/Alien/Package/Rpm.pm line 155.

In dem Artikel http://forum.ubuntuusers.de/topic/kivio-2-0-installieren/#post-2054853 habe ich dann eine Lösung gefunden. Dort ist ein kleiner Patch zu finden, der das Problem in der Zeile 155 angeht.

sub unpack {
	my $this=shift;
	$this->SUPER::unpack(@_);
	my $workdir=$this->unpacked_tree;
	my $rpmunpack="rpm2cpio ".$this->filename." | lzma -d | ";

	$this->do($rpmunpack."(cd $workdir; cpio --extract --make-directories --no-absolute-filenames --preserve-modification-time) 2>&1")
	      or (($rpmunpack="rpm2cpio ".$this->filename." | ")
	      and $this->do($rpmunpack."(cd $workdir; cpio --extract --make-directories --no-absolute-filenames --preserve-modification-time) 2>&1"))
	      or die "Unpacking of '".$this->filename."' failed";

	# cpio does not necessarily store all parent directories in an
	# archive, and so some directories, if it has to make them and has
	# no permission info, will come out with some random permissions.
	# Find those directories and make them mode 755, which is more
	# reasonable.
	my %seenfiles;
	open (RPMLIST, $rpmunpack."cpio -it --quiet |")
		or die "File list of '".$this->filename."' failed";

Ich habe einfach die entsprechenden vorhandenen Zeilen auskommentiert und diese Zeilen hineinkopiert. Nach der Änderung konnte ich mein Majordomo-Paket erfolgreich konvertieren mittels:

sudo alien --scripts majordomo-1.94.5-457.1.i586.rpm

Herzlichen Dank an den Autor hakunamatata.

Da in meinen Webserver-Log-Dateien häufiger Anfragen nach Dateien namens wpad.dat auftauchten habe ich mich mal mit dem Thema Web Proxy Autodiscovery Protocol (WPAD) beschäftigt. Positiv daran ist, dass es als Webstandard gilt und von allen aktuellen Browsern unterstützt wird. WPAD benutzt Proxy Auto-Configuration (PAC) Dateien um die Einstellungen zu übermitteln.

Diese Dateien dienen dazu Browser automatisch zu konfigurieren, so dass sie sich die Proxy-Einstellungen selbständig erfragen können. Grundlage dafür ist eine Konfigurationsdatei namens wpad.dat, die im einfachsten Fall folgenden Inhalt besitzt:

function FindProxyForURL(url, host)
{
  if(isPlainHostName(host) || localHostOrDomainIs(host, "localhost") ||  localHostOrDomainIs(host, "127.0.0.1") || isInNet(host, "192.168.1.1", "255.255.0.0")) {
     return "DIRECT";
  }else {
     return "PROXY 192.168.1.1:3128";
  }
}

Im Prinzip wird hier in der letzten Zeile die Adresse und der Port des Proxy-Server übergeben. Der Teil davor umgeht den Proxy-Server, wenn ein Rechnername ohne Domain aufgerufen wird, der Name oder die IP für localhost oder ein Rechner aus dem lokalen Netz.

Detaillierte Informationen findet man unter http://findproxyforurl.com und natürlich http://de.wikipedia.org/wiki/WPAD.

Diese Datei muss nun nur noch zum Browser kommen. Dazu muss der Browser passend eingestellt sein: Bearbeiten -> Einstellungen -> Erweitert -> Netzwerk -> Verbindung -> Einstellungen -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen

Nun muss auf dem Server noch der Webserver-Apache entsprechend konfiguriert werden. Er sollte im Idealfall auf folgende URL hin die Datei ausliefern: http://wpad.<rechnername.lokale-domain>/wpad.dat In den meisten Installationen langte es sicherlich im Nameserver einen cname für wpad einzurichten:

wpad       CNAME   boss

Zusätzlich wird noch empfohlen die zugehörigen Mime-Types zu registrieren. Dazu kommen folgende Zeilen in die bisher leere Datei /etc/apache2/httpd.conf:

AddType application/x-ns-proxy-autoconfig .dat
AddType application/x-ns-proxy-autoconfig .pac
Redirect permanent  /proxy.pac /wpad.dat

Hier sind zwei Dateien eingetragen, die wpad.dat und die proxy.pac, die beide identisch sind. Eine Version ist für WPAD-fähige Systeme zuständig, die andere für ältere Versionen. Durch den Redirect muss nur eine der beiden Dateien wirklich vorhanden sein. Anfragen an die andere Datei werden passend weitergeleitet.

Im Prinzip suchen die Browser nun nach einem festen System nach der Konfigurationsdatei. Man kann ihnen das Leben erleichtern und auch den cname wpad für den Webserver vermeiden, wenn man die DHCP-Server Konfiguration etwas anpasst.

# /etc/dhcpd.conf
#
# Configuration file for ISC dhcpd
#
# -- global options --
default-lease-time                 160000;
max-lease-time                     200000;
use-host-decl-names                on;
option dhcp-max-message-size       1024;
option wpad code 252 = text;
ddns-update-style                  none;
authorative;

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.40 192.168.1.160;
    server-identifier 192.168.1.1;
    option broadcast-address 192.168.1.255;
    option routers 192.168.1.254;
    option domain-name-servers 192.168.1.1, 192.168.1.254;
    option domain-name "debacher.net";
    option wpad "http://www.debacher.net/wpad.dat ";
}

Die beiden hinzuzufügenden Zeilen sind fett unterlegt. Damit wird dem Client-Rechner schon beim Starten die Adresse der wpad.dat (Code 252) mit übermittelt. Hier ist eine beliebige URL möglich, die auch nicht unbedingt im eigenen Netz liegen muss. Die Adressübermittlung per DHCP hat übrigens Vorrang gegenüber der Übermittlung per DNS. Man muss also nicht unbedingt an den Nameserver heran.

Weitere Informationen:

Ich wollte mich gern mit der erschreckenden Gesichtererkennung des neuen Picasa 3.6  beschäftigen. Leider bietet Google keine aktuellen Versionen für Linux an. Unter http://www.mail-archive.com/google-labs-picasa-for-linux@googlegroups.com/msg01748.html habe ich einen Beitrag gefunden mit dessen Hilfe ich 3.6 erfolgreich unter Ubuntu 9.10 installieren konnte.

Die Beschreibung geht davon aus, dass man Picasa 3.0 auf dem eigenen Rechner installiert hat. Ich hatte das schon vor einiger Zeit gemacht. Das Picasa 3.0 findet sich dann unter /opt/google auf dem Rechner.

Zuerst lädt man sich die Datei picasa36-setup.exe von der Google-Download-Seite.

cd /opt/google/picasa/3.0/wine/bin
./wine /home/debacher/Downloads/picasa36-setup.exe

Dabei wird Picasa in das Verzeichnis /home/debacher/.wine installiert. Soll es allgemein zur Verfügung stehen, so muss diese Installation nach /opt verschoben werden. Dazu benötigt man Root-Rechte:

sudo su -
cd /opt/google/picasa/3.0/wine/drive_c/Program\ Files/Google/
rm -Rf Picasa3
cp -R /home/debacher/.wine/drive_c/Programme/Google/Picasa3/  .
cd Picasa3
mv PicasaUpdater.exe PicasaUpdater.exe.old

Danach startet dann zukünftig Picasa 3.6 auch über alle Menüeinträge der alten Installation. Man kann dann sogar das gesamte .wine Verzeichnis im Homeverzeichnis löschen, zumindest wenn es nicht vorher schon vorhanden war.

Zum Fernsehen benutze ich gern Kaffeine, zumal es auf breiten Monitoren den Vorteil besitzt, dass die Senderliste seitlich sitzt und das Bild dadurch recht groß werden kann. Mit dem aktuellen Kaffeine hatte ich das Problem, dass manchmal kein Sound zu hören war, der Sound ging nicht auf meine analogen Boxen, sondern auf den digitalen Monitor.  Beim Start von Kaffeine tauchte dann immer eine Fehlermeldung von Phonon auf:

Phonon: Das Multimediasystem von KDE
Das Audio-Abspielgerät "HDA NVidia (ALC888 Analog)" funktioniert nicht. Es wird auf ... ausgewichen.

Ich habe lange verzweifelt nach einer Einstellmöglichkeit gesucht. Irgendwann habe ich dann das Programm pavucontrol installiert und damit versucht das digitale HDMI-Gerät zu deaktivieren. Aber auch das hat keinen nachhaltigen Effekt gebracht.

Nur hat sich dann irgendwann bei eine späteren Start von Kaffeine ein KDE-Programm gemeldet um mir mitzuteilen, dass ich ein Gerät deaktiviert habe. Dieses Programm bot eine Konfiguration des Soundsystems an.

/usr/bin/kcmshell4   kcm_phonon

Führt mich nun zu diesem Einstellprogramm, in dem man die Reihenfolge der Ausgabegeräte festlegen kann. Hier habe ich die HDMI-Ausgabe auf den letzten Platz gesetzt und nun wird auf PulseAudio ausgewichen, was dann auch funktioniert.

Auf meinem neuen Rechner habe ich mir Virtualbox installiert und zwar die nicht freie Version direkt von den Webseiten. Nun geht es darum die vorhandenen Images für Virtualbox verfügbar zu machen.

Wenn es irgend geht, dann sollte man noch unter VMWare die VMWare-Tools deinstallieren, sonst kann es später Probleme mit der virtuellen Netzwerkkarte geben. Unter Virtualbox ist die Deinstallation nicht immer möglich.

Meine VMWare-Images sind alle aufgeteilt in Dateien zu maximal 2 GByte. Im ersten Schritt müssen diese Teile zusammengefasst werden. Dazu wechsle ich ins Verzeichnis des jeweiligen Images und gebe ein:

vmware-vdiskmanager -r winXPPro.vmdk -t 0 /tmp/winXPPro.vmdk

Die Dateinamen müssen natürlich den eigenen Gegebenheiten angepasst sein.  Auf alle Fälle entsteht in /tmp die neue Datei mit der kompletten virtuellen Festplatte. Diese Datei kann nun für Virtualbox konvertiert werden. Dieser Schritt könnte entfallen, da Virtualbox inzwischen auch mit den VMWare-Images umgehen kann.

Im Ordner /tmp rufe ich dann auf:

VBoxManage -nologo clonehd winXPPro.vmdk winXPPro.vdi -format VDI

Das Virtualbox-Programm meldet sich mit einem textbasierten Fortschrittsbalken.

Der VBoxManager  speichert die neue Datei übrigens nicht in /tmp ab, sondern im Verzeichnis /home/<benutzer>/.VirtualBox/HardDisks. Man sollte sich gut überlegen, ob man diese Images wirklich in einem verborgenen Unterverzeichnis im Homeverzeichnis haben möchte.  Ich sammle diese großen Dateien gern auf einer extra Partition, was die Daten-Sicherung deutlich vereinfacht.

Nun kann man dieses Festplattenimage in eine neue virtuelle Maschine einbinden. Im dritten Fenster der Einrichtung einer neuen virtuellen Maschine kann man die Datei nun auswählen, indem man zuerst Festplatte benutzen auswählt und dann unten rechts auf das gelbe Ordnersymbol klickt. Hier kann man dann die Festplatte hinzufügen und auswählen.

Wenn die neue virtuelle Maschine eingerichtet ist, dann muss man unbedingt noch einmal auf den Bereich System doppeklicken, um dort eine Einstellung zu ändern. Bei mir wollte das Windows nie starten, wenn nicht der Schalter IO-APIC aktivieren gesetzt war.

Danach kann man dann die virtuelle Maschine starten. Sowie das Windows läuft sollte man die VMWare-Tools deinstallieren, da die zumindest die Netzwerkkarte stören. Besser wäre es diese schon vorher unter VMWare zu tun.

Nach den fälligen Windows-Neustart kann man dann die Virtualbox-Erweiterungen installieren.

Die VMWare Workstation 6.5.x lässt sich unter Ubuntu 9.10 nicht direkt installieren. Die Installation bleibt immer nach etwa 2/3 hängen, während die Konfiguration erfolgen soll. Mittels dmesg kann man sehen, dass vmmon geladen und entladen wird, die anderen Module lassen sich anscheinend nicht übersetzen.

Nach mehreren vergeblichen Versuchen habe ich im Ubuntu-Forum die Lösung gefunden http://ubuntuforums.org/showthread.php?t=1314006.

Der Autor schiotz löst das Problem über ein kleines Python-Script, welches er unter dem Namen gcc im gleichen Verzeichnis ablegt, wie die Datei VMware-Workstation-6.5.3-185404.i386.bundle. Ursache des Problems sind wohl zu viele Warnungen des Compilers, die zum Einfrieren der Installation führen. Also wird über dieses Script der gcc veranlasst schweigsamer zu sein.

#!/usr/bin/python

import sys
import copy
import os

argv = copy.copy(sys.argv)

i = len(argv)
for i in range(i-1, 0, -1):
    if len(argv[i]) > 4 and argv[i][:2] == "-W" and argv[i][3] != ",":
        del argv[i]

argv[0] = "/usr/bin/gcc"
os.execv(argv[0], argv)

Das Script und die Datei VMware-Workstation-6.5.3-185404.i386.bundle müssen ausführbar gemacht werden, danach kann die Installation mittels

sudo env PATH=`pwd`:$PATH ./VMware-Workstation-6.5.3-185404.i386.bundle

durchgeführt werden. Im Prinzip passiert hier nicht mehr, als dass der Pfad um das aktuelle Verzeichnis erweitert wird, damit der Fake-gcc anstatt des richtigen gcc aufgerufen wird.

Anschließend muss man dann noch die Module installieren mittels:

sudo vmware-modconfig –console –install-all --appname="VMware Workstation" --icon="vmware-workstation"

durchgeführt werden.

Bei mir lief vmware nach diesem Schritt bereits.

Zuletzt soll man noch die Datei /etc/vmware/bootstrap um die Zeile

VMWARE_USE_SHIPPED_GTK=force

erweitern.

Eine andere Lösung für das gleiche Problem findet sich unter http://linux.aldeby.org/vmware-workstation-6-5-3-on-ubuntu-karmic-9-10.html .