Mails im Ausland über deutsche SMTP-Server

Posted on by

Immer wieder begegnet man dem Problem, dass man bei Auslandsaufenthalten genötigt wird, für den Mailversand den SMTP-Server desjenigen Providers zu verwenden, an dessen Netzwerk man gerade angebunden ist. Ich stosse auf dieses Problem u.a. immer wieder in Norwegen (Telenor, Tele2) und Frankreich (Orange, France Telekom, Bouygues, Free(box)).

Die Provider filtern Zieladressen für eine SMTP-Kommunikation (Port 25), die sich nicht auf den Provider-eigenen SMTP-Server beziehen. Angeblich, weil man auf diesem Wege Spam-Probleme besser in den Griff bekommen will. Na ja, wer’s glauben mag ….

Das Problem ist der dadurch für den Anwender generierte Aufwand. In der Regel hat man den Mail-Client (MUA, bei mir Kmail) auf seinem Notebook/Laptop ja so vorkonfiguriert, dass als SMTP-Server in der Regel ein Server des hauseigenen deutschen Providers eingestellt ist.

[Es kann aber auch auf Laptops noch komplizierter sein – nämlich dann, wenn ein eigener SMTP-Server, evtl. sogar ein lokaler SMTP-Server auf dem Laptop mit einer Relay-Server-Anbindung die SMTP-Kommunikation handhabt (z.B. in Form eines lokalen Postfix MTA mit einem IMAP MDA wie Cyrus) ].

In jedem Fall aber ärgert man sich bei Auslandsreisen jedesmal über die Notwendigkeit einer Re- oder Zusatzkonfiguration des Mail-Clients oder aber anderer Mailkomponenten (wie Postfix).

Am Schluss schleppt man eine Liste ausländischer SMTP-Server in seinen Mail-Programmen herum, aus der man je nach Standort einen bestimmten Server als den aktuellen Standard definieren muss. Schon bei manchen MUAs ist das ein Thema, denn der Mailclient sollte dann so intelligent ist, mehrere account-übergreifende SMTP-Server verwalten zu können ….

Bei einigen der ausländischen Netze habe ich deshalb mal mit einigen Linux-Tools überprüft, ob tatsächlich nur der Port 25 gefiltert wird. Dies war der Fall. Da kommt man dann auf den Gedanken, ob nicht ein anderer Port den Zugang zum SMTP-Server eines meiner deutschen Provider ermöglichen würde.

Man denkt dabei an eine TLS/SSL-Anbindung – in Frage kommen die Ports 465 und 587.

Und ja, tatsächlich ist bei zweien meiner deutschen Provider entweder der Port 465 (SMTP via SSL) oder der Port 587 zugänglich. Einer der Provider verwendet 465 in Kombination mit SMTP-AUTH, beim Port 587 ist eine Authentifizierung sowieso zwingend vorgeschrieben. Auf dem Mail-Client müssen dann natürlich die notwendigen Einstellungen für eine SMTP-Authentifizierung vorgenommen werden – was bei Kmail kein Problem darstellt.

Eine Anbindung über einen der beiden Ports 465 oder 587 kann man natürlich auch aus dem Inland vornehmen. Damit ist dann die Chance gegeben, im Inland wie auch in vielen ausländischen Netzwerken seinen Mailversand über den gewohnten SMTP-Server seines Vertrauens abzuwickeln. Standortspezifische Einstellungen entfallen dann. (Nebenbei finde ich, dass nicht jeden Provider mein Mail-Gebaren etwas angeht).

Nach meinen Erfahrungen klappt das Verwenden der Alternativports mindestens mal in Norwegen und Frankreich bestens – gefiltert wird dort nur der Port 25. Natürlich muss aber auch der eigene deutsche Provider mitspielen und die genannten Ports anbieten …..

Es lohnt sich bei häufigen Auslandsaufenthalten aber wirklich, das abzufragen und seine Mailprogramme (einmalig) auf einen der Ports 465 opder 587 umzustellen. Viel Spaß nun beim Mailen im Ausland !

Links:

http://de.wikipedia.org/wiki/E-Mail-Programm
http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
http://de.wikipedia.org/wiki/SMTPS
http://de.wikipedia.org/wiki/SMTP-Auth
http://forum.df.
eu/forum/showthread.php?t=49183

KDE 4.4, Kontact, Kmail und das Adressbuch

Posted on by

In einem Beitrag am 25.12.2009 hatte ich nach einer ersten Entäuschung geschrieben, dass man den Weg zu KDE 4.4 noch nicht im produktiven Umfeld beschreiten sollte. Inzwischen habe ich diese Zurückhaltung aufgegeben – ich setze KDE 4.4 nun produktiv ein und fühle mich in dieser Desktop-Umgebung in der täglichen Arbeit gut unterstützt.

Entsprechend habe vor kurzem einem Kollegen empfohlen, doch mal KDE 4.4 auszuprobieren. Er fand das auch gut, kam aber nicht mir der Einrichtung von Kontact/Kmail klar. Sein Kontact Adressbuch funktionierte zwar irgendwie, aber er konnte die Adressen nicht unter Kmail nutzen. Das verstehe ich gut, weil ich selber große Schwierigkeiten hatte, die aktuelle Philosophie für Kontacts Adressbuch nachzuvollziehen.

Daher auch an andere Interessierte oder Betroffene zwei Hinweise:

1) Das “Default Adress Book” unter “Kontakte” ist nicht das “Default Adressbook” unter “Kmail” !

Ich habe das aktuelle Vorgehen der KDE-Entwicklung aus einem Forum-Dialog wie folgt verstanden: Offenbar gibt es den Plan, in der Zukunft diverse Ressourcen des KDE-Desktops über einen lokalen Akonadi-Server bereitzustellen. Um sich systematisch an das Thema heranzutasten, wurde Kontacts Adressbuch als erste Applikation auf Akonadi umgestellt. Das, was man als Unbedarfter dann erwartet, ist natürlich, dass das “neue” Akonadi-basierte Adressbuch auch unter Kmail genutzt werden kann.

Nun, da irrt man. Das Akonadi-basierte “Default Adressbook” im Adressbereich von Kontact ist im Moment (!) keineswegs ein Adressbuch, welches von anderen Kontact-Applikationen genutzt werden würde oder könnte – auch wenn unter Kmail in diversen Dialogfenstern ein “Default Adress Book” aufgeführt wird.

Wenn ich das richtig sehe, so ist das Akonadi-basierte Adressbuch zur Zeit das Ergebnis eines ersten Test- und Übungsbeispiels für die KDE-Entwickler – das verwirrende Resultat für den normalen Anwender ist bislang eine “stand alone”-Lösung, die im Kontakte-Bereich von Kontact als (sinnentleerte?) Zugabe herumgeistert. Dieses Adressbuch wird im PIM nicht von anderen Applikationen benutzt !

So ist es auch kein Wunder, dass mein Freund und ich verzweifelt, aber vergeblich Testeinträge im Adressbuch anlegten, um dann herauszufinden, dass diese unter Kmail (z.B. im Rahmen der automatischen Adress-Vervollständigung) nicht angezeigt werden – obwohl sie natürlich in voller Schönheit im Adressbuch-Bereich such-, sicht- und editierbar sind. Da half und hilft kein Rumprobieren an den Einstellungen des Kmail-Editors oder das Verändern der Adressbuch-Reihenfolge – das unter diversen Kmail erwähnte “Default Adress Book” hat halt leider rein gar nix mehr mit dem im Adressbuch-Bereich angelegte “Default Adress Book” zu tun.

Liebe KDE-Truppe, der/die dafür Verantwortliche sollte wissen, dass sich das einem Anwender wahrlich nicht erschließt. Mit einer solchen Idee rechnet man schlicht nicht – ich selbst konnte es nach Jahren KDE-Verwendung auch überhaupt nicht glauben und habe das Ganze erst nach mehrmaligem Lesen eines Dialogs zwischen einem frustrierten Anwender mit einem KDE-Entwickler begriffen. Wenn man die User beim Umstieg auf KDE 4.4 verwirren wollte – dann wurde dieses Ziel in preisverdächtiger Weise erreicht.

Als fehlersuchender KDE-Anwender experimentiert ja man nicht nur mit Kontact-Einstellungen herum – nein, man wirft natürlich auch einen Blick auf den Akonadi-Server und die dort erscheinenden Ressourcen. Dieser Ausflug in eine bislang unerforschte Welt war natürlich hochinteressant – aber er nutzt einem bzgl. des Kmail-Problems nichts. Unter Akonadi erschien bei mir alles fehlerfrei – sprich der Akonadi-Server lief anstandslos und die Adressbuch-Ressource wurde auch angezeigt. Nur unter Kmail ließen sich die Adressen halt nicht verwenden.

Übrigens: Falls man bei der Einrichtung von Akonadi Probleme
haben sollte, hilft vielleicht Folgendes:

a) Virtuoso installieren

b) Bzgl. der Desktop-Suchmaschine Nepomuk folgenden Eintrag in der Datei “~/.kde4/share/config/nepomukserverrc” prüfen:

[main Settings]
Maximum memory=50
Storage Dir[$e]=$HOME/.kde4/share/apps/nepomuk/repository/main/
Used Soprano Backend=virtuosobackend

c) Ggf. “~/.config/akonadi/akonadiserverrc” löschen und den Akonadiserver über die Akonadi-Einrichtung neu starten

2) Lösung: Ignoriere im Moment das Akonadi-basierte Adressbuch und richte ein konventionelles Adressbuch unter Kontakt und ggf. auch unter KDE ein!

Hat man die obige “Philosophie” erst einmal verdaut, ist natürlich der Weg zur Lösung nicht weit. Man muss in Kontacts Adressbuch-Bereich (und ggf. unter den KDE-Ressourcen; s.u. den Hinweis vom 25.06.2010) einfach ein weiteres “Standard”-Adressbuch einrichten.

Zum Einrichtungs-Dialog für ein neues Adressbuch kommt man durch einen Klick mit der rechten Maustaste in den Seitenbereich “Adressbücher” unter “Kontakte”. Im erscheinenden Kontextmenü wählt man dann “Adressbuch hinzufügen”. In der nachfolgenden Auswahl schließlich “KDE-Adressbuch (herkömmlich)”. Es erscheint erneut ein Auswahldialog – hier muss man die für sich richtige Ressource anklicken. In meinem Fall ist das ein Adressbuch eines Open-Xchange-Servers, für das man dann die Verbindungsdaten wie in früheren Kontact-Versionen auch einträgt:

Adresse: http://my-OX-Server
User: my_user_name
Passwort: my_password

Danach Auswahl des OX-Adressbuch-Verzeichnisses – z.B. des globalen Adressbuches unter den OX-Systemordnern. Dieses so angelegte Adressbuch erscheint dann übrigens auch als Akonadi-Ressource – was einem unter Kmail aber leider nichts nutzt. ..

*******Wichtige Ergänzung vom 25.06.2010: *******
In der bei mir aktuellen Version (Kontact 4.4.5 und KMail 1.13.5) aus dem Factory-Repository von SUSE reicht der eben beschriebene Schritt unter “Kontakte” leider nicht (mehr?) aus, um die Ressource auch im KMail-Bereich verfügbar zu machen (z.B. für die automatische Adressvervollständigung). Vielmehr muss man die Adressbuch-Ressource nochmals manuell anlegen – und zwar in den KDE- “Systemeinstellungen” als allgemeine KDE-Ressource:

Entweder im KDE-Menü “Systemeinstellungen” starten oder in einem Terminalfenster “system-settings &” eingeben. Dort den Reiter “Erweitert” betätigen und dann den Eintrag “KDE-Ressourcen” wählen. Mit Hilfe der Auswahl-Combobox die Kategorie “Kontakte” einstellen. Prüfen, ob die gewünschte Adressbuch-Ressource schon als Eintrag vorhanden ist. Wenn – wie bei mir – nicht: “Hinzufügen” anklicken und in den folgenden Dialogen zum Hinzufügen einer Ressource die gleichen Schritte vornehmen, die oben für den “Kontakte”-Bereich von “Kontact” beschrieben wurden.

Im aktuellen Zustand von Kontact führt das Anlegen einer (herkömmlichen) Adressbuch-Ressource unter “Kontakte” offenbar nicht mehr zu den notwendigen KDE-Einträgen für die Ressourcen, die dann von KMail aufgegriffen werden. Was denkt der normale Anwender: Schade eigentlich … und regt sich am besten nicht auf ….
****** Ende Ergänzung 25.06.2010 *******

Hinweis: Für ein lokales Adressbuch sollte die zugehörige Datei übrigens auf

/home/user_xyz/.kde4/share/apps/kabc/std.vcf

verweisen, wenn das vcf-Format gewählt wurde.

Die so angelegten (herkömmlichen) Adressbücher werden schließlich auch unter Kmail erkannt und an den gewohnten Stellen aufgelistet. Der Adressbuch-Inhalt wird auch wie gewohnt in der automatischen Adress-Suche und -Vervollständigung beim Verfassen von Mails herangezogen. Die Reihenfolge, in der die “herkömmlichen” Adressbücher dabei verwendet werden sollen, legt man mit den üblichen Dialogen, z.B.
“Einstellungen – Kmail einrichten – E-Mail-Editor –
Vervollständigungsreihenfolge einstellen ….”,
fest. Alles wie gehabt. Ich kann seitdem wieder normal arbeiten.

Links

Einen Sinn hatte das ganze Theater aber doch: Man fängt an, sich für Akonadi zu interessieren. Als Einstieg hier ein paar Links:

http://de.wikipedia.org/wiki/Akonadi
http://pim.kde.org/akonadi/
http://userbase.kde.org/Akonadi

Schön ist übrigens die Einleitung zur UserBase (mit Hinweisen zur Fehlerbehebung):

“This page is mainly concerned with troubleshooting Akonadi, as there are inevitable glitches in early stages of migration. For many people the first signs of Akonadi activity will be in KDE SC 4.4, and many will be confused by it. ”

Oh, yes !

Dell M90, Suse 11.2, KDE 4.4, VMware – Teil II

Posted on by

Wie im vorhergehenden Artikel beschrieben, habe ich auf einem Dell 90 eine vorhandene Win XP Installation (32Bit, mit mehreren aktiven physikalischen Partitionen) um eine Opensuse 11.2-Installation ergänzt. Zunächst lag also eine Dual-Boot-Konfiguration vor. Das Management der verschiedenen Möglichkeiten beim Booten übernimmt bei mir Grub, das ich im MBR des Systems installiert habe.

Das eigentliche Ziel war es aber, die vorhandene 32Bit-Windows-Installation auch in einer virtuellen VMware-Maschine unter dem 64 Bit Opensuse 11.2 Linux-System verfügbar zu machen. Danach liegt dann natürlich nach wie vor eine Dual-Boot-Konfiguration vor. Der Unterschied ist aber der, dass das bereits installierte Windows auch nach dem Booten des Linux-Systems vollständig über VMware zugänglich wird – nämlich als Gastsystem. Ein und dasselbe Win XP kann in dieser angestrebten Zielkonfiguration dann also

  • sowohl als natives OS gebootet und betrieben werden
  • als auch als Gast einer VMware-Maschine unter der Regie des 64-Bit Linux-Hosts gebootet und genutzt werden – also im sog. “Raw-Modus” von VMware.

Dass eine solche Konfiguration reizvoll ist und viele Vorteile bietet, liegt auf der Hand. Ich wollte das schon lange mal ausprobieren. Nun ist das in meinem Fall erfolgreiche Vorgehen, das ich nachfolgend beschreibe, nicht wirklich auf meinem Mist gewachsen, sondern basiert auf Informationen aus verschiedenen Quellen. Zitieren möchte ich stellvertretend vor allem folgende 5 Artikel, die mir sehr geholfen haben :

http://www.vmware.com/pdf/dualboot_tech_note.pdf

http://www.informatik-forum.at/showthread.php?t=56924

http://wiki.ubuntuusers.de/VMware/Parallelsystem

http://www.gentooforum.de/post/106994/vmware-und-windows-von-eigener-partition-starten-vorgehensweise.html

http://www.kvaes.be/unix-linux/running-your-dual-boot-windows-inside-vmware-server-within-ubuntu/

http://linux.derkeiler.com/Mailing-Lists/SuSE/2007-12/msg00401.html

Hinweis und Disclaimer

Es ist durchaus gefährlich, eine solche Konfiguration ohne hinreichendes Wissen einzurichten. Das nachfolgend beschriebene Vorgehen funktioniert möglicherweise nicht auf Ihrem System! Kleine Fehler haben u.U. zudem fatale Folgen. Ein Totalverlust der installierten Systeme und der dort vorhandenen Daten kann die sehr wahrscheinliche Folge sein. Dies gilt für das vorhandene Linux- wie das Windows-System. Es handelt sich beim beschriebenen Vorgehen also um ein Experiment (!) mit potentiell großer bis maximaler Schadenswirkung. Man sollte eine solche Installation keinesfalls auf Produktiv-Systemen vornehmen. (Zumindest nicht ohne vorherige hinreichende Tests in einer unproduktiven Umgebung) Eine vollständige System- und Datensicherung ist obligatorisch, bevor man beginnt. Ein Problem ist eher wahrscheinlich als unwahrscheinlich!

Damit das klar ist: Ich übernehme keinerlei Haftung für evtl. Schäden als Folge des nachfolgend beschriebenen Vorgehens – weder an der Hardware, noch an der Software oder Daten. Ich garantiere auch nicht die Richtigkeit und Anwendbarkeit der nachfolgenden Schritte. Jeder, der dem beschriebenen Vorgehen auf seinem eigenen System folgt, tut das vollständig und in jeder Hinsicht auf eigenes Risiko.

Hingewiesen sei auch darauf, dass selbst im Fall einer erfolgreichen Konfiguration eine Reaktivierung des Win XP-Systems anstehen kann. Hier muss man im Besitz einer passenden Lizenz sein. Beachten Sie auch entsprechende Hinweise in den zitierten Artikeln und Blog-Beiträgen. Übrigens: Nach einer Reaktivierung von Win XP steht das gleiche Spielchen mit hoher Wahrscheinlichkeit auch für proprietäre SW wie MS Office oder Adobes Creative Suite an. Es lohnt sich daher wirklich, sich vorab intensiv mit der Lizenzfrage und ein paar BIOS-bezogenen Einstellungen der VM zu befassen (s. u.a. die Hinweise im dritten oben zitierten Artikel).

Vorsichtsmaßnahmen:

  1. Da im hier gewählten Vorgehen mindestens der erste Boot-Vorgang in der virtuellen Maschine zu einer Anzeige der Grub-Optionen führt, besteht die Gefahr, das bereits laufende Linux-System oder eine Variante davon auch in der virtuellen Maschine zu starten. Das darf man aber auf keinen Fall tun – es würde zu einer Zerstörung der gesamten Linux-Installation führen !
  2. Evtl. Timeout-Parameter im Boot-Menü sind daher vorab vorsichtshalber zu entfernen ! Ferner sollte man vor dem ersten Start der einzurichtenden virtuellen Maschine unter Grub “Windows” als das standardmäßig zu bootende System einstellen !
  3. Die Windows-Partitionen dürfen beim Starten der virtuellen Maschine nicht unter Linux gemountet sein! Zumindest als beschreibbare Devices – also nur “read only” ! Eventuelle andere Einträge in der “/etc/fstab” sind zu entfernen ! Vor dem ersten Start der virtuellen Maschine muss unbedingt der Mount-Zustand per mount-Befehl geprüft werden !

Nach diesen Warnungen nun eine Beschreibung des Vorgehens, das bei mir zum Erfolg geführt hat:

Schritt 1: Vorbereitung des Win-XP-Systems auf 2 verschiedene HW-Umgebungen

VMware gaukelt dem späteren Gastsystem Win XP natürlich eine etwas andere Hardware vor, als die, die es bei einem direkten nativen Booten vorfindet. Das Win XP muss sich der neuen “virtuellen” HW anpassen können, ohne die ursprünglichen Einstellungen für einen nativen Boot-Vorgang zu verlieren. Um das zu erreichen, benutzt man unter Win XP die Möglichkeit zum Einstellen sog. “Hardwareprofile”.

Die SATA-Disk des Dell M90 erschient unter dem Kernel des Opensuse 11.2 Linux als “/dev/sda”, wird also über die Gerätetreiberschicht wie eine SCSI-Disk behandelt. Nun kann man auf dem Win XP-System prophylaktisch den VMware-SCSI-Treiber installieren, um später die virtuelle Maschine betreiben zu können. Hierauf gehen einige der oben zitierten Artikel ein. Alternativ kann man aber die SATA-Disk im Gastsystem auch als IDE-Disk betreiben – so sieht es schließlich ja auch das native WinXP. Man muss sich nun für einen Weg entscheiden. Ich bin bislang nur den Weg über den IDE-Treiber gegangen, der evtl. nicht die optimale Performance liefert. Er erschien mir aber einfacher und hat auf Anhieb funktioniert. Hinzu kommt, dass man in VMware-Unterlagen den Hinweis findet, dass diese Variante besser getestet sei.

Zusätzlich ist zu beachten, dass in dem später geltenden Hardwareprofil statt eines speziellen Intel-Treibers der native MS IDE-ATA-Treiber geladen werden muss. Nur dieser passt beim ersten Booten des Gastsystems zur IDE-Harddisk der virtuellen VMware-Maschine. (s. aber den Hinweis am Ende des Artikels).

Duchzuführen sind demnach also folgende Unterschritte:

  • Booten von Win XP (aus der Dual-Boot-Konfiguration). Systemsteuerung aufrufen. Systemsteuerung -> System -> Reiter Hardware -> Hardwareprofile.
  • Im
    Dialog eine Kopie des aktuellen Profils anlegen.
  • Umbenennen des originalern Profils in “Standalone” und des neuen in “VMware”. Dies nur zur besseren späteren Unterscheidbarkeit.
  • Anklicken der Option “Warten, bis ein Hardwareproil gewählt wird” unter dem Punkt “Beim Starten von Windows”
  • Wechsel zum “Geräte-Manager”. Dort “IDE-Controller” auswählen. -> “Treiber aktualisieren” -> “…. den zu installierenden Treiber selbst wählen” -> “Standard-Zweikanal-PCI-IDE-Controller” auswählen und aktivieren.
  • Win XP herunterfahren – Linux booten.

Schritt 2: Einrichten der virtuellen Maschine unter VMware (im Linux System)

Man boote Linux. Danach VMware installieren. In meinem Fall die Workstation 7. Das Ganze geht aber auch mit VMware Server 1.x. Da man später beim Booten der virtuellen Maschine auf die gesamte Festplatte zugreifen wird, ist es nötig, den User, der über VMware ein existierendes System von einer physikalischen Partition booten will, mit hinreichenden Rechten auszustatten. Unter Opensuse bedeutet das, den betreffenden User zu einem Mitglied der Gruppe “disk” zu machen. Danach richtet man dann die virtuelle MAschine ein.

  • Opensuse: Gib dem User, der VMware benutzt, die Mitgliedschaft in der Gruppe “disk”. Per Yast oder mit dem Befehl “sudo adduser myusernamedisk”.
  • Nun geht es an das Einrichten einer geeigneten virtuellen Maschine. Hier folgt man dem entsprechenden Dialog mit der Option “Custom”. In meinem Fall habe ich folgende Einstellungen gewählt:
  • Workstation 6.5-7.0 bei der HW Compatibility
  • “I will install the operating system later” bei den Einstellungen zur Installation
  • Win XP Pro bei den Einstellungen zum geplanten OS
  • Number of Processors: 2
  • Number of Cores per Processor
  • Memory: 800 MB
  • Network Adapater Bridged (für Verbindungen nach außen)
  • Network Adapter 2 Host-Only (für Verbindungen zum Host bei ggf. fehlendem Netz)
  • “Use a physical disk” (+ “use entire disk”; s. hierzu die Anmerkungen weiter unten) [“Hard Disk (IDE) Using device /dev/sda “]

Hinweise zur SATA-Platte
Bzgl. der SATA-Harddisk ist anzumerken, dass ich vergeblich versucht habe, über die VM-Einrichtung eine individuelle Partition anzusprechen. Danach schlug das Booten der virtuellen Maschine regelmäßig fehl. Ferner gibt es das Problem, dass VMware für das Einrichten der Harddisk nur die Möglichkeit einer SCSI-Disk anbietet. Der Grund dafür ist vermutlich, dass die SATA-HD unter Linux als SCSI-Device geführt wird (/dev/sda). Damit bootet das virtuelle System aber nicht – zumindest nicht, wenn man nicht vorher den entsprechenden SCSI-Treiber von VMware installiert hat. Dieses Vorgehen habe ich aber, wie gesagt, nicht ausprobiert.

Notwendige Schritte zur Einrichtung der SATA-Harddisk:

  • Die gesamte Harddisk auswählen, d.h. im entsprechenden VMware-Dialog als device /dev/sda angeben und den Radiobutton “use entire disk” anklicken.

    • n

  • Im Einrichtungsdialog trotz allem Buslogic als SCSI-Controller auswählen. Nach dem Aufsetzen der virtuellen Maschine muss dann ein manuelles Nacheditieren der Dateien .vmdk und .vmx erfolgen :
  • vmx-File: hier die wichtigen Einträge bzgl. der Platte
  • ide0:0.present = “TRUE”
  • ide0:0.fileName = “WinXP0.vmdk”
  • ide1:0.present = “TRUE”
  • ide1:0.fileName = “/dev/sr0”
  • ide1:0.deviceType = “cdrom-rawk”
  • scsi0.present = “TRUE”
  • scsi0:0.redo = “”
  • scsi0.pciSlotNumber = “16”
  • ide0:0.redo = “”

Beim “fileName” muss natürlich das richtige File angegeben sein. Der überflüssig wirkende “scsi0.present”-Eintrag sorgt dafür, dass der SCSI-Treiber geladen wird (sicherheitshalber, falls man den später doch mal braucht).

  • vmdk-File: hier die wichtigen Einträge bzgl. der Platte
  • ddb.adapterType = “ide”

An den Geometriedaten der Disk habe ich nichts geändert !

Weitere Hinweise zur Einrichtung der VM:
Zu den 2 ausgwählten Prozessoren ist zu sagen, dass das auf einem Dual Core-System von VMware eigentlich nicht empfohlen wird. Ich hatte aber auch dem Dell mit der VMware WS 7 den Eindruck, dass das probemfrei geht und der VM insgesamt zu mehr Performance verhilft. Der USB-Controller wurde automatisch erkannt, die Soundkarte und das (Vmware-) Display ebenfalls. Das CD/DVD Drive wurde automatisch als IDE erkannt: “CD/DVD (IDE) Using drive /dev/sr0”.

Schritt 3: Ändern der Grub-Einstellungen

Nun muss man zur Sicherheit die Grubeinstellungen verändern. Ein schnelles Starten des bislang in Grub vermutlich als “Standard” oder “Default” eingerichten Linux-Systems muss verhindert werden. Hierzu muss man entweder die Datei “/boot/grub/menu.lst” editieren oder unter Opensuse das Yast-Tool zum Einstellen der erforderlichen Punkte heranziehen.

  • Setzen des “default” Eintrages in der “/boot/grub/menu.lst” auf den korrekten Wert für den Eintrag zum Booten des Windows-Systems (Achtung: Die Einträge in der Datei menu.lst werden ab 0 hochgezählt! Ist der dritte Eintrag derjenige, der sich auf das Windows-System bezieht, so ist also ein Eintrag “default 2” richtig.) Man prüfe die neue Einstellung für das als Standard zu bootende System über einen Neustart !
  • Um das automatische Booten zu deaktivieren, löscht man entweder die Zeile “timeout”. Nach erfolgreicher default-Eintrags-Änderung gem. 3.1) – aber nur dann – kann man den Tinmeout-Eintrag ggf. auch auf einen hohen Wert (z.B. 1800) setzen, um den Boot-Vorgang lang genug hinauszuzögern. Auch diese Einstellung kann man in einem Reboot testen.

Schritt 4: Check /etc/fstab und aktuell gemountete Devices

Hier sollte man überprüfen, dass keine der möglichen Windows-Partitionen des Systems unter dem Linux-Host-System gemountet ist – zumindest nicht in einem Modus, in dem auf das Device geschrieben werden kann.

Schritt 5: Erstmaliges Starten der virtuellen Maschine

Nun kann man die virtuelle Maschine erstmalig starten. Das Starten erfolgt hier über den Boot-Sektor der Platte! Deshalb sollte nun auch das vollständige Grub-Menu erschienen – u.a. mit dem Windows Eintrag als ausgewähltem Standard-System zum Booten.

  • Bitte nun wirklich mehrfach verifizieren, dass im Grub-Menu nun das Windows-System für den Boot-Vorgang ausgewählt ist. (Ein Booten des bereits aktiven Linux-Systems würde natürlicherweise – wie oben angemerkt – zu einer Katastrophe und zu einem völlig inkonsistenten Filesystem führen!)
  • Danach Win XP in der virtuellen Maschine booten.
  • Auswahl des richtigen (!) Hardwareprofils: Nun sollte als erstes eine Rückfrage bzgl. des auszuwählenden Hardwareprofils erscheinen. Auch hier bitte extrem vorsichtig sein und das für vmware erstellte Profil (in unserem Beispiel mit “VMware” bezeichnet) auswählen. Alles andere kann bei einem späteren nativen Boot des Windows-Systems zu erheblichen Problemen führen.
  • Boot-Vorgang fortsetzen. Das sollte nun funktionieren und zwar ohne Blue Screen. Wenn man einen Blue Screen erhält und bzgl. des IDE-ATA-Contollers alles richtig gemacht hat, hilft nur, das Win XP nach einem nativen Booten über den Gerätemanager ggf. so zu entschlacken, dass es auch in der virtuellen Umgebung läuft. Auf meinem Dell 90 M gab es allerdings kein Problem.
  • Am Login-Schirm einloggen und ggf. Win XP reaktivieren! Zu der Frage, ob eine zweite Lizenz erforderlich ist oder nicht, siehe etwa die Diskussion unter http://forum.ubuntuusers.de/topic/windows-xp-aktivierung. Siehe auch den dritten der oben zitierten Artikel für weitere Hinweise bzgl. der BIOS-Einstellungen für die virtuelle Maschine.
  • Nun die VMware-Tools für den Windows-Gast wie gewohnt installieren.

Hinweis zu den VMware-Tools
Ich habe den VMware-Tools-Service später in den “Dienste”-Einstellungen von Win XP als manuell zu startenden Dienst konfiguriert, um bei einem nativen Windows-Boot nicht laufend mit Problemmeldungen konfrontiert zu werden. Ich habe nicht genau untersucht, woher die Meldungen kommen; vermutlich rühren sie ja daher, dass der dann der Host gesucht wird, aber nicht vorhanden ist. Ggf. resultieren die Probleme aber auch daher, dass mein Win XP selbst eine VMware-Server-Installation beherbergte. Dass ich nun in der virtuellen Maschine, VMware-Tools manuell starten muss, stört mich persönlich nicht; hier würde vermutlich aber auch ein wenig Skripting unter Windows weiterhelfen)

Schritt 6: Testen der normalen Windows-Installation nach einem Reboot

Nachdem die virtuelle Maschine funktioniert, sollte man auf jeden Fall nach einem Reboot des gesamten Systems auch noch die Funktionstüchtigkeit der Win XP-Installation im normalen nativen Modus checken. Auch ein Blick in den “Gerätemanager” könnte von Interesse sein.

Bzgl. der Harddisk stellte ich nach einigem Gebrauch des Win XP Systems sowohl in nativer Form als auch als VMware-Gastsystem fest, dass am Schluss folgender Treiber geladen wurde:

Intel(R) 82371AB/EB PCI-Bus-Master-IDE-Controller

Im Gegensatz zum Treiber, der im nativen XP geladen wird, operiert dieser Treiber nur im UDMA 2-Modus. Ich habe sicherheitshalber bislang nicht versuchen, das zu ändern.

Schritt 7: Einrichten einer virtuellen Floppy für das Booten oder
Entfernen von Grub

Um die Gefahr eines versehentlichen Bootens des Host-Linux-Systems im Grub-Menü nach dem Start der virtuellen Maschine zu vermeiden, empfiehlt es sich über eine virtuell eingebundene Floppy zu booten. Hier erspare ich mir eine Beschreibung, da diese vollständig und nachvollziehbar in einem der oben zitierten Artikel (aus dem gentooforum) enthalten ist.

Der oben zitierte Ubuntu-Artikel beschreibt, wie man alternativ die Kopie (!) des MBR, die in der virtuellen Maschine gezogen wird, und damit dann auch auch Grub in der virtuellen Maschine entfernt. Dadurch habe ich übrigens gelernt, dass der MBR in der VM ein kopierter ist. Darüber hatte ich vorher, ehrlich gesagt, noch nie nachgedacht. Erscheint im nachhinein aber als logisch. Man lernt halt nie aus!

Nun viel Spass mit Win XP in einer VM im Raw-Modus auf einem Linux-Host !