Selbstverständlich gibt es eine Alternative zum derzeit fast überall eingesetzten Master Boot Record (MBR), diese Alternative heißt GUID Partition Table (GPT). Nun ist das Problem, dass die Unterstützung für GPT sowohl im BIOS als auch beim Bootmanager (z.B. Grub) vorhanden sein muss. Auf x86-basierenden Systemen (üblicherweise als x86, IA32, x86_64, AMD64, EM64T bekannt) ist eine Unterstützung von GPT bislang allgemein recht selten und aktuell unterstützt keine für den Unternehmenseinsatz optimierte Linux-Distribution die GPT von Haus aus.

Natürlich könnte man einen Grub 2 (der sowieso noch Zukunftsmusik ist) selbst compilieren oder den bestehenden Grub 0.x mit einem Patch aufbohren, aber das muss hinterher selbst gepflegt sowie gewartet werden und bei Problemen ist man auf sich selbst gestellt.

Die Lösung ist nun bei einem RAID-Controller den RAID-Verbund anderst aufzubauen: Hat man z.B. nur Festplatten mit jeweils 1 TB, so plant man üblicherweise ein RAID 5 mit 5 Festplatten und einer Hotspare-Platte. Eine mögliche, funktionierende Lösung wäre ein RAID 1 aus 2 Festplatten, sowie ein RAID 5 aus 5 Festplatten und eine globale Hotspare-Festplatte. In diesem Fall müsste man einfach noch zwei weitere Festplatten dazukaufen, um die gleiche Nutzkapazität zu erreichen. Auf das RAID 1 wird das Betriebssystem mit einem MBR installiert, auf das RAID 5 wird eine GPT eingerichtet und anschließend hat man 4 TB für Nutzdaten. Und die globale Hotspare springt entweder für das RAID 1 oder das RAID 5 ein – je nach dem, wo sie bei Bedarf benötigt wird.

Bei Verwendung eines Red Hat Enterprise Linux 5 (RHEL) bzw. CentOS 5 kann eine ganz normale Installation auf dem RAID 1 durchgeführt werden. Anschließend wird das RAID 5 mit GPT eingerichtet wie folgt:

[root@tux ~]# parted /dev/sdb
GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted)
(parted) p

Model: DELL PERC 6/i (scsi)
Disk /dev/sdb: 3999GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End  Size  File system  Name  Flags

(parted)
(parted) mkpart
Partition name?  []? BACKUP
File system type?  [ext2]? ext3
Start? 0
End? -1
(parted)
(parted) p

Model: DELL PERC 6/i (scsi)
Disk /dev/sdb: 3999GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name    Flags
 1      17.4kB  3999GB  3999GB               BACKUP

(parted)
(parted) quit
Information: Don't forget to update /etc/fstab, if necessary.

[root@tux ~]#

Anschließend kann mit mkfs.ext3 ein Dateisystem angelegt werden. Wichtig ist noch, dass fdisk aktuell nur mit MBR-Partitionstabellen und nicht mit GPT umgehen kann. Somit muss in jedem Fall zu parted (GNU Parted) gegriffen werden. Übrigens, MBR-Partitionstabellen und Partitionen größer als 2 TB lassen sich problemlos anlegen, konfigurieren und selbst ein Dateisystem lässt sich darauf anlegen. Aber sobald Daten ins Spiel kommen, geht das ganze schief. Einige Leute beschreiben zudem, dass die Beschränkung sich lediglich auf Partitionen größer als 2 TB beziehen würde und Partitionstabellen größer als 2 TB möglich wären – dies habe ich so nicht nachvollziehen können: Egal ob Partition oder Partitionstabelle, sobald die 2 TB-Grenze erreicht war, gab es bei mir Probleme.

Bei RAID beziehe ich mich überall auf ein Hardware-RAID, da ein Software-RAID zum einen immer eine schlechtere Performance als ein Hardware-RAID liefert und zum anderen, da sich dieses Problem auch nicht mit einem Software-RAID lösen lässt.

Die Verwendung eines Logical Volume Managers (LVM) wäre sicherlich auch noch eine Möglichkeit, hätte es nicht im Linux-Kernel unter Verwendung von LVM2, wie er mit allen gängigen Enterprise-Distributionen mitgeliefert wird, bis vor kurze Zeit einen schwerwiegenden Fehler gegeben, der im Extremfall bei 100% Schreibgeschwindigkeit für lediglich 50% Lesegeschwindigkeit gesorgt hat. Das Problem wurde erst mit einer Testversion des Linux-Kernels in Version 2.6.27 behoben und wird aufgrund von Inkompatibilitäten vermutlich auch in keine bestehende Version einer Enterprise-Distribution zurückportiert werden. Red Hat behandelt dieses Problem aktuell im von mir geöffneten Bugreport 147679 und geht davon aus, es mit Red Hat Enterprise Linux 6 (und damit auch CentOS 6) zu beseitigen…

Die Kommunikation im Internet läuft über sogenannte IP-Adressen. Wenn Sie also “www.etes.de” in Ihrem Webbrowser eingeben, so kommunizieren die Rechner und Server untereinander mit der IP-Adresse “91.196.144.19″ anstatt “www.etes.de”. Dieses IP-Schema heißt IPv4 wurde im Jahr 1983 begonnen und erlaubt maximal 4 294 967 296 IP-Adressen. Damals war das kein Problem, nur Universitäten und wenige große Firmen hatten einen Zugang zum Internet; es gab folglich nur wenige Großrechner, die miteinander vernetzt werden konnten.

Heute, im Jahr 2008, haben wir mobile Geräte wie Handys, Organizer und PDAs, mit denen wir überall ins Internet gelangen können. Selbst manche Waschmaschine oder Kaffeemaschine hat bereits einen Netzwerkanschluss, Internet gehört inzwischen einfach zum täglichen Leben, viele haben zudem einen Internetanschluss oder nutzen UMTS. All das sind Dinge, die im Normalfall jeweils mindestens eine IP-Adresse benötigen.

Wenn Sie nun den Screenshot auf der linken Seite anschauen (Quelle: Intec NetCore, Inc.), dann sind sämtliche IP-Adressen in voraussichtlich 794 Tagen an Provider und Internetanbieter vergeben. Sind alle IP-Adressen vergeben und ein Provider hat mehr Kunden, die gleichzeitig ins Internet möchten, als ihm IP-Adressen zugewiesen worden sind, so können einige oder vielleicht gar viele Kunden nicht mehr ins Internet.

Deshalb wurde bereits im Jahr 1999 eine Lösung für dieses Problem entwickelt: IPv6 als Nachfolger von IPv4. Mit IPv6 sind maximal 340 282 366 920 938 463 463 374 607 431 768 211 456 IP-Adressen möglich – ein vielfaches vom derzeit genutzten IPv4-Schema. Zudem wurden mit IPv6 auch technische “Designfehler” der Vergangenheit ausgebügelt und es wurde allgemein an der Verwendbarkeit im Hinblick auf mobile Systeme gearbeitet.

Jedoch sieht eine IPv6-Adresse wie 2001:0db8:e3e0:afb2:9837:500d:89cd:921d völlig anderst als die oben genannte IPv4-Adresse aus. Und dort beginnen die Probleme bereits: Alle Geräte, die jetzt mit Netzwerk zu tun haben, müssen dann IPv6-tauglich sein. In erster Linie betrifft das die Software, die auf den Geräten läuft, also das Betriebssystem, den Webbrowser, den E-Mail-Client, den Netzwerk-Drucker etc. Denn mit einer IPv6-Adresse kann man leider keine IPv4-Adresse erreichen und umgekehrt sowieso nicht.

Wir selbst haben seit vorgestern von unserem Provider eine IPv6-Anbindung (eine native Verbindung folgt in 3-4 Monaten) auf unserer Standleitung aufgeschaltet bekommen und haben darüber ein paar IPv6-taugliche Webseiten aufgerufen. Und aktuell sind wir erst der fünfte Kunde unseres Providers, der IPv6 bereits nutzen möchte. Da IPv6 gänzlich zu scheuen auf Dauer keine Lösung ist, werden wir in den nächsten Monaten versuchen, unser Netzwerk im Büro langsam zusätzlich mit IPv6 zu versehen. Dabei werden wir sicherlich Probleme identifizieren, aber gleichzeitig auch Lösungen dafür suchen, damit Sie als Kunde rechtzeitig von unserer Erfahrung in diesem Bereich profitieren können und eine problemlose und rechtzeitige Migration Ihrer IT-Umgebung möglich ist, wenn IPv6 in vermutlich 2-3 Jahren das jetzige IPv4-Schema ersetzen wird!

Dieses Problem haben wir recht einfach gelöst, da man seit Samba 3 die SID vom alten Server auf den neuen Server einfach mitnehmen kann – was leider etwas ungünstig und weniger klar dokumentiert zu sein scheint. Wenn nun eine Domäne “ETES” vorhanden ist, so muss man entweder vor der Umstellung oder auf dem alten Server die SID ermitteln:

[root@alt ~]# net getlocalsid ETES
SID for domain ETES is: S-1-5-21-6129332212-1304462674-322571322
[root@alt ~]#

Diese SID wird auf den neuen Server übernommen. Zwar kann die SID für jede Domäne ermittelt werden, doch nicht ohne weiteres mit dem gleichen Syntax gesetzt werden: Denn der Aufruf “net setlocalsid” erlaubt ausschließlich die Angabe der SID und keiner Domäne! Und statt der Domäne nimmt Samba scheinbar fast immer den NetBIOS-Namen aus der Samba-Konfiguration an…

Der Trick an dieser Stelle ist nun, in der Datei “/etc/samba/smb.conf” im Abschnitt “[global]” den Wert von “netbios name” temporär auf den Namen der Domäne zu setzen, also z.B.

[global]
    netbios name = ETES

Anschließend ist eine Änderung der SID möglich:

[root@neu ~]# set getlocalsid S-1-5-21-6129332212-1304462674-322571322
[root@neu ~]#

Zur Sicherheit sollte das Ergebnis noch einmal geprüft werden:

[root@neu ~]# net getlocalsid ETES
SID for domain ETES is: S-1-5-21-6129332212-1304462674-322571322
[root@neu ~]#

Liefert dies jetzt auf dem neuen Server auch wieder die alte SID zurück, so war die Migration erfolgreich und der NetBIOS-Name kann entweder wieder deaktiviert oder auf den alten Wert zurückgestellt werden.

Abschließend können sich die auf die Domäne gejointen Clients mit Microsoft Windows einfach wieder ganz normal an der Samba-Domäne anmelden, als hätte es diese Server-Umstellung nie gegeben – es ist auch kein Rejoin notwendig.

In seltenen Fällen kann es vorkommen, dass die SID nicht mitgenommen werden kann, dann muss zusätzlich zu einem Rejoin in die neue Samba-Domäne auch die SID in der NTUSER.DAT auf die neue aktualisiert werden, andernfalls verweigert Microsoft Windows üblicherweise die Benutzung des Profils:

[root@samba ~]# profiles -c S-1-5-21-6129332212-1304462674-322571322-2056 \
  -n S-1-5-21-7623811015-3361044348-030300820-2056 NTUSER.DAT
[root@samba ~]#

Falls die alte SID nicht bekannt ist, so kann diese z.B. mit “strings” aus den binutils ermittelt werden:

[root@samba ~]# strings NTUSER.DAT | grep S-1
S-1-5-21-6129332212-1304462674-322571322-2056
S-1-
[root@samba ~]#

Mit diesem beschriebenen Weg sollte die Migration einer Samba-Domäne kein schweres oder gar unüberwindbares Hindernis mehr darstellen.