sudo apt-get install openssh-server ia32-libs

Danach können die drei Pakete Client, Node und Server (gibt es hier) in dieser Reihenfolge installiert werden:

(Versionsnummern anpassen!)

sudo dpkg -i --force-architecture nxclient...._i386.deb
sudo dpkg -i --force-architecture nxnode...._i386.deb
sudo dpkg -i --force-architecture nxserver...._i386.deb

Jetzt sollte sich eine Verbindung zum Server herstellen lassen.

Raid-Controller: LSI 1068
Netzwerkkarten: Broadcom BMC 5715
CPU: AMD Opteron 2344 HE, Quad-Core der Barcelona-Serie
RAM: 4 GB DDR2-RAM ECC

Nach einiger Recherche kamen wir zu dem Ergebnis: diese wichtigen Kernkomponenten werden vom ESX allesamt unterstützt.

Die Installation des ESXi

Die Installation gestaltet sich jetzt etwas komplizierter. An einigen Stellen sollte sehr aufgepasst werden, da Befehle verwendet werden, die potenziell Daten zerstören können, daher bitte immer darauf achten, dass der Befehl beim ersten mal passt (und in der richtigen Konsole ausgeführt wird).

Die Installation geschieht in 3 Schritten:

1. Vorbereitungen
Der ESXi verfügt über einige Sicherheitsvorkehrungen, die verhindern sollen, dass der ESXi ungewollt falsch verwendet wird. Dazu gehört zum Beispiel auch eine Überprüfung der MAC-Adressen beim Starten. Wenn sich diese ändert, wird die Netzwerkkarte deaktiviert.
Aus diesem Grund wird als erstes die MAC-Adresse des Zielsystems benötigt. Diese kann durch den Befehl "ifconfig" im laufenden Linux des Rootservers herausgefunden werden.
Der Server kann zudem schonmal im Rescuemodus hochgefahren werden.
Außerdem sollte die VmWare Workstation installiert sein. Hier reicht die kostenlos bei VmWare erhältliche 30-Tage-Testversion. Es bietet sich jedoch an, eine Lizenz der Workstation zu kaufen, da sich diese prima eignet, um die VMs aufzusetzen, die später im ESXi laufen sollen. Zudem muss darauf geachtet werden, dass es sich um eine neuere Version handelt (bei uns Version 6.5 Build 126130), da der ESXi auf älteren Versionen nicht läuft.
Außerdem muss bei 64-Bit-Systemen im BIOS die Hardwarevirtualisierung eingeschaltet sein.

Der Server, der schon im Rescue-Modus läuft, muss nun temporär etwas angepasst werden. Dazu startet man

cfdisk /dev/sda

und löscht alle vorhandenen Partitionen. Dann werden zwei neue erstellt. Die erste sicherheitshalber 20 GB, die zweite mit dem Rest der Festplatte (eigentlich RAID).
Die zweite wird nun mit

mfks.ext2 /dev/sda2

formatiert. Die erste Partition dient nur als Platzhalter und wird nicht weiter verwendet.
Dann wird die formatierte Partition mit

mount /dev/sda2 /mnt

gemountet.

2. Vorbereitung einer VM für den ESXi
Um einen ESXi als VM ans laufen zu bringen sind einige Modifikationen an den Konfigurationsdateien einer virtuellen Maschine nötig. Am einfachsten geht es wohl, die folgenden Zeilen in eine .vmx-Datei zu kopieren und dann in Workstation entsprechend anzupassen:

.encoding = "windows-1252"
config.version = "8"
virtualHW.version = "7"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "1024"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "anthill.vmdk"
ide1:0.present = "TRUE"
ide1:0.autodetect = "TRUE"
ide1:0.deviceType = "cdrom-image"
floppy0.present = "FALSE"
ethernet0.present = "TRUE"
ethernet0.connectionType = "bridged"
ethernet0.wakeOnPcktRcv = "FALSE"
svga.autodetect = "TRUE"
mks.enable3d = "FALSE"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
roamingVM.exitBehavior = "go"
displayName = "Anthill"
guestOS = "other"
nvram = "anthill.nvram"
deploymentPlatform = "windows"
virtualHW.productCompatibility = "hosted"
easyInstall.removeFloppy = "FALSE"
unity.customColor = "|23000000"
tools.upgrade.policy = "useGlobal"

extendedConfigFile = "anthill.vmxf"

ide1:0.fileName = "D:\Software\Images\kubuntu-8.04-desktop-amd64.iso"

ethernet0.addressType = "generated"
uuid.location = "56 4d 50 b3 6d cc d9 ea-43 27 69 e1 61 3d 96 c4"
uuid.bios = "56 4d 50 b3 6d cc d9 ea-43 27 69 e1 61 3d 96 c4"
scsi0:0.redo = ""
vmotion.checkpointFBSize = "16777216"
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "16"
ethernet0.pciSlotNumber = "32"
vmci0.pciSlotNumber = "33"
ethernet0.generatedAddress = "00:0c:29:3d:96:c4"
ethernet0.generatedAddressOffset = "0"
vmci0.id = "-646518333"
ethernet0.virtualDev = "e1000"
monitor.virtual_exec = "hardware"
monitor_control.restrict_backdoor = "true"

tools.syncTime = "FALSE"

scsi0:1.present = "TRUE"
scsi0:1.fileName = "anthill-0.vmdk"

scsi0:1.redo = ""

vmi.present = "FALSE"

vmi.pciSlotNumber = "-1"

debugStub.linuxOffsets = "0x0,0xffffffff,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0"

ethernet1.present = "TRUE"
ethernet1.connectionType = "hostonly"
ethernet1.wakeOnPcktRcv = "FALSE"

ethernet1.addressType = "generated"
ethernet1.pciSlotNumber = "34"
ethernet1.generatedAddress = "XXXXXXXXXXXXXXXXXXXXXXXXX"
ethernet1.generatedAddressOffset = "10"

In der zweitletzten Zeile müssen die vielen X durch die MAC (aus Punkt 1) ersetzt werden.
Dann kann Workstation gestartet und diese Datei geladen werden. Als nächstes klickt man auf "Edit Virtual Machine Settings" -> "Hardware". Sobald man auf die Platten klickt, wird Workstation feststellen, dass die zugehörigen Dateien fehlen. Also die alten löschen und neu anlegen:

Die erste als virtuelle Platte, SCSI (LSI Logic), 8 GB vorallokiert.
Die zweite dient lediglich zum Extrahieren des Systems aus der ersten. 1 GB reicht völlig aus.

3. Installation des ESXi in der lokalen VM

Die soeben erstelle VM kann nun gestartet werden. Als CD wird das Image der ESXi-Installationscd "eingelegt". Beim ESXi kann getrost immer auf weiter geklickt werden. Es sollte natürlich die 8GB Platte ausgewählt werden (falls die andere überhaupt angezeigt wird).

Nachdem die Installation abgeschlossen ist: NICHT REBOOTEN!

Der ESXi darf nicht von der VM-Platte gestartet werden. Stattdessen wird nun eine beliebige Linux-Live-CD eingelegt und diese gestartet.

4. Kopieren des Systems

In einer Root-Console des Livesystems in der VM muss jetzt das Image erstellt werden, welches nachher auf den Server geladen wird.

fdisk -l

wird nun die zwei VM-Festplatten anzeigen. /dev/sda enthält zahlreiche ESXi-Partitionen, während /dev/sdb unpartitioniert bleibt.
Auf /dev/sdb wird nun eine Partition mit der vollen Größe angelegt. Diese wird anschließend formatiert und z.B. nach /mnt gemountet.
In /mnt wird nun folgender Befehl ausgeführt:

dd if=/dev/sda | gzip > esximage.gz

Dieser Befehl liest die Festplatte /dev/sda komplett aus (sind ja nur 8GB) und komprimiert diese in gerademal 200MB und speichert sie in der neu erstellten Partition.
Die Datei esximage.gz enthält jetzt alles was nötig ist, um den ESXi zu installieren. Sie muss jetzt auf den Server nach /mnt kopiert werden. Dies geht direkt mit SSH aus der VM heraus.

Damit ist die Arbeit der lokalen VM erledigt. Workstation kann beendet werden.
Nun wird eine Konsole auf dem Server geöffnet. Im Verzeichnis /mnt wird der folgende Befehl ausgeführt:

gunzip -c esximage.gz | dd of=/dev/sda

Dieser sorgt dafür, dass das Image entpackt und auf der Platte gespeichert wird. Dabei wird selbst die aktuell verwendete Partitionstabelle überschrieben. Um sicher zu gehen, dass alle Daten geschrieben werden, wird der Befehl sync ohne Parameter aufgerufen.
Nachdem das Rescuesystem ausgeschaltet wird, kann der Server von my.serverloft.de aus hardresettet werden. Dadurch wird sichergestellt, dass keine Daten mehr am Anfang des RAID-Verbundes geschrieben werden.

Nun sollte der ESXi-Server vom RAID aus Booten. Der Infrastructure Client sollte sich mit dem Server verbinden können. nmap zeigt etwa folgendes Bild:

Starting Nmap 4.62 ( http://nmap.org ) at 2008-12-02 00:11 CET
Interesting ports on loft3333.serverloft.de (12.23.23.34):
Not shown: 1710 closed ports
PORT     STATE    SERVICE
80/tcp   open     http
427/tcp  open     svrloc
443/tcp  open     https
902/tcp  open     iss-realsecure
6667/tcp filtered irc

Nmap done: 1 IP address (1 host up) scanned in 1.510 seconds

Achtung: der ESXi läuft jetzt ohne Passwort! Dieses sollte sofort mit Hilfe des VmWare Infrastructure Clients gesetzt werden!

Der Standardlogin mit dem Infrastructure Client funktioniert als Benutzer "root" ohne Passwort.

Der installierte ESXi besitzt bis jetzt noch keine Partition, auf der die VMs abgelegt werden können. Diese kann jedoch leicht angelegt werden. Die weitere Vorgehensweise findet sich in den sehr detailreichen Handbüchern des ESXi.
Außerdem sollte natürlich nicht vergessen werden, den Lizenzkey einzutragen!

VmWare Infrastructure Client auf frisch installiertem ESXi

In diesem Sinne auch an einen Dank an Serverloft.
Die Bestellung bei Serverloft ging erstaunlich schnell von Statten. Von der Order bis zur Betriebsbereitschaft vergingen nur 55 Minuten, obwohl Serverloft zuerst mit meiner spanischen Handynummer nicht einverstanden war. Eine Mail an den Support klärte den Sachverhalt und der Server wurde ohne Rückruf freigeschaltet.

Die dafür zuständigen Optionen sind EmulateWheel und EmulateWheelButton. Um diese für den Trackpoint zu ändern, benötigt man seinen Namen oder seine Device-ID. Der Name ist je nach Hardware unterschiedlich, bei meinem Dell Latitude E6400 heißt er DualPoint Stick. Herausfinden kann man ihn mit xinput:

$ xinput list | grep "DualPoint Stick"
"DualPoint Stick" id=4 [XExtensionPointer]


Die bereits gesetzten Optionen kann man sich ebenfalls anzeigen lassen:

$ xinput list-props "DualPoint Stick"
Device 'DualPoint Stick':
Device Enabled:        1
Middle Button Emulation:        2
Middle Button Timeout:        50
Wheel Emulation Inertia:        10
Wheel Emulation:        0
Wheel Emulation X Axis:        0, 0
Wheel Emulation Y Axis:        4, 5
Wheel Emulation Timeout:        200
Wheel Emulation Button:        2
Drag Lock Buttons:        0

Um die Scrollfunktion für die aktuelle Sitzung zu aktivieren, reichen die Befehle
$ xinput set-int-prop "DualPoint Stick" "Wheel Emulation" 8 1
$ xinput set-int-prop "DualPoint Stick" "Wheel Emulation Button" 8 2

Ersteres aktiviert die Scrollfunktion, zweiteres setzt die Taste, mit der das Scrollen ausgelöst wird. Da der Wheel Emulation Timeout standardmäßig auf 200ms gesetzt ist (siehe oben), muss man auch nicht auf die Paste-Funktion der mittleren Maustaste verzichten. Drückt man die Taste kurz, wird ein normaler Mittelklick ausgelöst. Drückt man sie länger, kann man scrollen. Den Timeout kann man natürlich auf dieselbe Weise anpassen.

Sollen diese Einstellungen dauerhaft gesetzt werden, kann man dies über HAL erreichen. Dazu erstellt man z.B. in /usr/share/hal/fdi/policy/20thirdparty eine Datei mit folgendem Inhalt:

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">

<device>
<match key="info.capabilities" contains="input">
<match key="info.product" contains="DualPoint Stick">
<merge key="input.x11_options.EmulateWheel" type="string">true</merge>
<merge key="input.x11_options.EmulateWheelButton" type="string">2</merge>
</match>
</match>
</device>

</deviceinfo>

Übermittelt der OpenVPN-Server dem sich verbindenden Client eine DefaultRoute, wird eine eventuell bereits bestehende nicht ersetzt bzw. überhaupt eine erstellt. Das Problem ist im Upstream-Projekt bekannt und bereits behoben, in Ubuntu 8.10 ist der entsprechende Patch jedoch noch nicht eingepflegt.

Als Workaround kann man in den Einstellungen der entsprechenden VPN-Verbindung die vom VPN-Server übermittelten Routen ignorieren lassen, woraufhin NetworkManager automatisch die DefaultRoute auf die VPN-Verbindung setzt. Die Option "Automatisch erhaltene Routen ignorieren" findet man in den Eigenschaften der VPN-Verbindung auf der Registerkarte "IPv4-Einstellungen" nach Klick auf den Routen-Button. Falls außer der DefaultRoute weitere Routen gesetzt wurden, muss man diese hier von Hand nachtragen.

Weiterführende Links:

• Bugreport auf gnome.org (http://bugzilla.gnome.org/show_bug.cgi?id=552594)
• Bugreport auf Launchpad (https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/269071)

An dieser Stelle sollte eigentlich das Kubuntu-Team ins Spiel kommen und sich entscheiden, weiterhin KDE3 in den Paketquellen (als Standard) anzubieten. Dies ist leider nicht der Fall. Durch das neue Release von Kubuntu, dem jüngst erschienenen 8.10, ist somit für viele Benutzer die Tür zur Linuxwelt zugefallen.
Ohne Zweifel wird jeder, der sich nicht auskennt, die neueste Software herunterladen, um herauszufinden, ob ihm diese gefällt oder nicht. Hier geht genau das verloren, wofür Ubuntu gestanden hat - das gewisse Einfache und Stabile.
Gut ding braucht Weil. So natürlich auch KDE4. In den nächsten Monaten werden hoffentlich die bisher mitunter ziemlich lausig portierten Programme auf ihr einstiges Niveau gebracht. Zusammen mit verbesserter Stabilität kann KDE4 und den bereits vorhandenen guten Ansätzen dann sicherlich der würdige Nachfolger von KDE3 werden. Solange gilt jedoch: Stabilität vor Optik; und Anwender, die mit ihrem Kubuntu arbeiten möchten, sollten mit dem Update auf 8.10 lieber noch warten.

Zudem bleibt nur zu hoffen, dass Nvidia reagiert und schnell die einst exzellenten Treiber für Linux wieder auf den aktuellen Stand bringt.

Wer dennoch einen Blick auf das neue KDE4.1 werfen möchte, dem sei gesagt, dass sich nach Erfahrung vieler Nutzer die Leistung von Nvidiakarten wohl verbessern lassen soll (war hier nicht nachvollziehbar). Ein tolles Plasmoid für die Toolbar ist übrigens Lancelot (Paket plasmoid-lancelot).
Wie alle vorherigen Versionen auch, kann 8.10 natürlich auch wieder von CD gebootet werden und von dort aus begutachtet werden, ohne die vorhandene Installation zu aktualisieren.

$ sudo apt-get install openoffice.org-base

nachinstalliert werden.

 
$ sudo passwd root
 

Während der Ausführung wird nach dem neuen Passwort gefragt. Danach sollte ein problemloses Einloggen als Root z.B. via "su" möglich sein.

Mar 30 17:39:24 abakus couriertcpd: couriertls: connect: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Um dieses Problem zu lösen muss in auf dem Server in der Datei /etc/courier/imapd-ssl ein Eintrag geändert werden.
Aus

TLS_STARTTLS_PROTOCOL=TLS1

wird je nach System

TLS_STARTTLS_PROTOCOL=TLS2

oder

TLS_STARTTLS_PROTOCOL=TLS3

Nach einem Neustart der Courier-Dienste (am besten alle)

 
$ for i in /etc/init.d/courier-* ; do $i restart ; done
 

sowie einem Neustart bzw. reconnects des Mail-Clients sollte die Kommunikation über SSL wieder funktionieren.